Introduction

The message Data at the root level is invalid usually comes from an XML parser in .NET. It means the parser expected an XML document to begin with its root element, but it found unexpected content before that point.

Understand What Valid XML Looks Like

An XML document may begin with an XML declaration, or it may begin directly with the root element. What it cannot have is random text, another document, or stray bytes before that root.

This throws the error because the string starts with invalid text:

1using System;
2using System.Xml.Linq;
3
4var broken = "OK<root><item>1</item></root>";
5
6try
7{
8    XDocument.Parse(broken);
9}
10catch (Exception ex)
11{
12    Console.WriteLine(ex.Message);
13}

The parser rejects OK because it is not valid at the start of the XML document.

Check Whether the Payload Is Really XML

A common real-world cause is trying to parse HTML, JSON, or plain text as XML. For example, an HTTP call may return a login page or proxy error page on failure, even if the success path returns XML.

Before parsing, inspect the raw payload.

1using System;
2using System.Net.Http;
3using System.Threading.Tasks;
4using System.Xml.Linq;
5
6static async Task LoadXmlAsync(string url)
7{
8    using var client = new HttpClient();
9    var response = await client.GetAsync(url);
10    var payload = await response.Content.ReadAsStringAsync();
11
12    Console.WriteLine(payload[..Math.Min(payload.Length, 80)]);
13
14    if (!payload.TrimStart().StartsWith("<"))
15    {
16        throw new InvalidOperationException("The response does not look like XML.");
17    }
18
19    var doc = XDocument.Parse(payload);
20    Console.WriteLine(doc.Root?.Name);
21}

If the payload does not begin like XML, the parser error is just a symptom of the wrong content type. Checking response headers alongside the payload preview often makes the problem obvious.

Watch for Encoding and Hidden Characters

Leading whitespace is usually fine, but hidden characters and broken encodings can still trip the parser. A copied byte order mark, mixed encodings, or text prepended by another system can all corrupt the start of the document.

If you know the source sometimes includes a stray Unicode marker, trim only the known unwanted prefix before parsing.

1using System;
2using System.IO;
3using System.Xml.Linq;
4
5var xml = File.ReadAllText("input.xml");
6xml = xml.TrimStart('\uFEFF', ' ', '\t', '\r', '\n');
7
8var doc = XDocument.Parse(xml);
9Console.WriteLine(doc.Root?.Name.LocalName);

Use this carefully. Trimming a known BOM is reasonable. Silently removing arbitrary leading content is not a real fix.

Diagnose the Raw Input First

When the exception says line 1, position 1, the bug is usually right at the beginning of the payload. That means the best debugging move is to log the raw bytes or at least the first visible characters.

Do not start by debugging the object model or the code that reads nested XML nodes. If the document never parses, the problem is earlier than that. Focus on what the parser received, how it was encoded, and whether another system inserted a prefix.

This shows up often in real integrations where a proxy, login gateway, or legacy service prepends text before the XML payload. The parser only reports the first invalid character it sees.

Common Pitfalls

• Assuming the response is XML without checking what the server actually returned.
• Looking only at the parsed object code instead of logging the raw payload.
• Ignoring encoding issues and hidden leading characters.
• Trimming arbitrary data until the parser stops complaining, which can hide a broken upstream source.
• Retrying the same parse instead of validating the input format first.

Summary

• The error means the parser found invalid content before the XML root element.
• Verify that the payload is actually XML before calling XDocument.Parse or similar APIs.
• HTML error pages, prefixed text, and encoding problems are common causes.
• Inspect the raw input first; the exception message alone is not enough.