Troubleshooting XML Namespace errors in Power Query.

XML Namespace errors occur in Power Query when importing XML feeds, SOAP services, or complex schemas that use namespace declarations (xmlns, xmlns:ns2, or custom prefixes). These namespaces cause Power Query’s Xml.Tables and Xml.Document functions to produce shifting column headers (such as appending full URLs to field names), fail during table navigation, or throw Expression.Error: The field '...' of the record wasn't found when schemas change between files.

Quick Answer

To fix XML namespace errors, strip the namespace attributes from the raw XML text before parsing it. Convert the XML binary to text, use Text.Replace or a clean-up pattern to remove xmlns="..." and xmlns:*="...", and then pass the cleaned text to Xml.Tables.

---

How XML Namespaces Disrupt Power Query

XML namespaces prevent element name collisions by qualifying tags with an identifier (often a URL). For example:

<invoice xmlns:inv="<http://accounting.example.com/orders>">
    <inv:id>10492</inv:id>
</invoice>

When Power Query’s automated XML connector reads this data via Xml.Tables, it tries to preserve the namespace. This causes three major structural problems:

1. Header Pollution: Power Query often prefixes every column name with the namespace alias or URL, generating headers like http://accounting.example.com/orders:id instead of a clean id.
2. Broken Step Dependencies: If the namespace prefix changes (for instance, if one file uses xmlns:ns1 and another uses xmlns:ns2), subsequent query steps like Table.SelectColumns fail immediately because the column names no longer match.
3. Empty Navigation Tables: In SOAP APIs, nested elements under namespaces often fail to expand into structured tables, leaving empty records or unexpandable binary objects.

To understand how shifting column names cause downstream query failures, see Fixing “Column Name Mismatch” when appending two tables.

---

Step-by-Step Diagnostic and Resolution Path

Method 1: Strip Namespaces at the Text Level (Recommended)

The most reliable way to handle troublesome namespaces is to strip them out before the XML engine parses the document. This normalizes all element names into plain XML tags.

1. In your query, locate the step that imports the raw XML file or API response (typically a binary or text step before Xml.Tables).
2. If your data is binary, convert it to text: XMLText = Text.FromBinary(Source, TextEncoding.Utf8)
3. Use Text.Replace to remove the primary namespace declarations: // Replace common XML namespace declarations with an empty string CleanedXML = Text.Replace(XMLText, "xmlns=""<http://schemas.example.com/default>""", "")
4. If your XML uses dynamic or varied namespaces, remove them using a generalized replacement function or pass the text through Xml.Tables: CleanedTable = Xml.Tables(CleanedXML)

All tags will now expand cleanly using simple, predictable column names (like id instead of ns2:id).

Method 2: Use Xml.Document Instead of Xml.Tables

The high-level Xml.Tables function attempts to automatically flatten structures, but it often mishandles namespaces. The lower-level Xml.Document function parses the data into a hierarchical tree of records, preserving the element structure without mangling table columns:

1. Change your import step from Xml.Tables(Source) to: SourceDoc = Xml.Document(Source)
2. Inspect the resulting tree. Elements appear in a table containing Name, Namespace, and Value.
3. Filter the Name column to target the records you need, regardless of what appears in the Namespace column.
4. Expand the child values manually.

This approach lets you extract values while ignoring namespace variations across different files.

Method 3: Handling SOAP Payloads and Web Endpoints

If your XML source is an enterprise web service, the namespace is often tied to the SOAP envelope:

<soapenv:Envelope xmlns:soapenv="<http://schemas.xmlsoap.org/soap/envelope/>">
   <soapenv:Body>
      <GetOrdersResponse xmlns="<http://api.company.com/>">

When parsing SOAP responses:

1. Strip the SOAP envelope tags (<soapenv:Envelope...>, <soapenv:Body>, and their closing tags) using text manipulation.
2. Read the remaining inner payload with Xml.Tables.
3. If you encounter connection breaks or invalid URI parameters when pulling from SOAP endpoints, refer to Troubleshooting Web.Contents errors: “The provided URI scheme is invalid.”

---

Resolving Character Encoding Issues in XML

If stripping namespaces still leaves you with parsing errors, inspect the file’s text encoding. XML files generated by legacy systems often use ISO-8859-1 or Windows-1252 encoding, while declaring encoding="utf-8" in the prologue.

When Power Query encounters a mismatch between the declared encoding and the actual byte stream, it throws a parsing error before it even reads the namespaces. To resolve encoding conflicts, specify the correct code page in your import step, or review Handling “Special Characters” (UTF-8 vs ANSI) in text imports.