XML Formatter Guide: Indent, Read, and Debug XML Documents

XML remains common in enterprise APIs, configuration formats, feeds, office documents, identity protocols, and legacy integrations.

Compact XML is difficult to review:

<users><user id="1"><name>Duck</name></user></users>

Duck Cloud's XML Formatter validates and indents XML locally in the browser.

Formatting reveals structure

Indented XML makes parent-child relationships visible.

That helps reviewers spot:

• elements in the wrong parent;
• missing closing tags;
• unexpected nesting;
• duplicated nodes;
• incorrect attributes.

Formatting is especially useful when an API response is technically one long line.

XML must be well formed

A document can fail parsing because of:

• mismatched tags;
• unescaped special characters;
• invalid attribute quoting;
• multiple root elements;
• broken entity references;
• malformed declarations.

A formatter generally needs to parse the input before it can indent it, so a syntax error may prevent formatting.

Use the reported failure location as a starting point and inspect the characters immediately before it.

Elements vs attributes

XML can represent data in several ways:

<user id="123">
  <name>Isaac</name>
</user>

Here id is an attribute while name is an element.

When integrating with an API or schema, do not move values between attributes and elements just because both are readable. The consumer may require the exact structure.

Escape special characters

Text containing XML-significant characters must be represented correctly.

For example, a raw ampersand can break XML if it is not part of a valid entity.

Do not “fix” XML by deleting characters from business data. Use a real XML serializer that performs correct escaping.

Namespaces

Namespaces can make XML look more complicated:

<example:item xmlns:example="https://example.com/ns">

The prefix itself is not the whole identity; namespace URI handling matters.

When debugging SOAP, SAML, or other namespace-heavy formats, compare the namespace declarations carefully.

XML vs JSON

Modern web APIs often use JSON because it maps naturally to JavaScript objects.

XML still has features and ecosystems where it remains important.

Do not convert formats solely for readability if the receiving protocol requires XML.

If you need to inspect JSON separately, use the JSON Formatter.

Security considerations

XML parsers have historically supported features such as external entities.

For untrusted XML, production applications should use secure parser configurations and disable dangerous features that are not needed.

Do not create your own XML parser using regular expressions.

Use maintained XML libraries appropriate for your platform.

API troubleshooting

When an XML API fails:

1. record the HTTP status;
2. inspect Content-Type with the HTTP Header Checker;
3. preserve the raw body;
4. format a safe copy;
5. check namespaces and required fields;
6. compare with a known-good request;
7. inspect server-side error details.

A syntactically valid XML document can still violate the API's schema.

Diff formatted XML

When comparing two XML payloads, format both first and then use Text Diff.

This reduces noise caused by one payload being compact and the other being indented.

XML checklist

• Preserve the raw original.
• Format a safe copy.
• Check opening and closing tags.
• Check escaping.
• Review attributes and required elements.
• Verify namespaces.
• Confirm response Content-Type.
• Use secure parser settings for untrusted XML.
• Validate against the relevant schema when the protocol defines one.

XML becomes much easier to debug once its hierarchy is visible. Format first, then separate syntax problems from schema and business-rule problems.