XML Linter Online

Well-formedness checks, xmllint commands and parser-error diagnosis. Reviewed September 30, 2026.

An XML linter checks whether a document is well-formed: one root element, matching opening and closing tags, valid nesting and escaped special characters. Formalint's XML formatter gives browser-based linting for everyday integration payloads, SOAP responses, feeds and configuration files.

Open the XML Formatter and Validator to lint and format XML in the browser.

Common XML Lint Errors

The most frequent XML lint failures are mismatched tag names, missing closing tags, unescaped ampersands, multiple root nodes and text that accidentally includes angle brackets. These are the same kinds of well-formedness problems developers often look for with xmllint.

<order>
  <id>1001</id>
  <status>paid</status>
</order>

When an XML Linter Helps

XML problems are often noisy because the real bug is several lines before the parser message. A missing close tag near the top of a feed can make a later field look broken, and one unescaped ampersand in a company name can stop a whole import job. Formatting first gives you predictable indentation, then linting tells you whether the document can be parsed at all.

For API work, use a linter before comparing two XML responses or converting XML to JSON. Clean indentation makes repeated nodes, attributes and text nodes easier to inspect, especially in SOAP envelopes, RSS feeds, sitemap files, vendor exports and older ERP integrations.

xmllint-style Checks vs XSD Validation

Formalint focuses on fast well-formed XML checks and readable formatting. It does not replace schema validation against a custom XSD or DTD. Use it first to make sure the document parses, then run schema validation when a vendor or API contract requires it.

Reproduce the Check with xmllint

# Check well-formedness without printing the document
xmllint --noout payload.xml

# Format a valid document to standard output
xmllint --format payload.xml

# Validate against an XSD after parsing succeeds
xmllint --noout --schema contract.xsd payload.xml

Read the first parser error before the cascade that follows it. A single missing quote or closing tag often causes several later messages. Keep the browser result and command-line result separate: identical failures suggest malformed input, while different failures may point to encoding, external entities or schema configuration.

Parse Error Triage

XML Review Checklist

Before sending an XML payload to another system, confirm that there is exactly one root element, every opening tag has a matching closing tag, attributes are quoted, special characters are escaped and repeated child nodes are intentionally repeated. If a partner gives you an XSD, validate against that schema after the well-formed check passes.

Frequently Asked XML Lint Questions

Does XML linting guarantee an API will accept my payload? No. Linting confirms the XML is well-formed. The receiving API may still reject a valid XML document if required nodes, attribute values or schema rules are missing.

Is xmllint the same as formatting? No. Formatting changes readability. Linting checks whether the XML can be parsed without structural errors.

Related Formalint Pages

Use XML Formatter and Validator for the live tool, Well-formed vs Valid XML before adding XSD checks, JSON Formatter after conversion, and the API Debugging Checklist when an integration fails in production.

Parsing success does not guarantee a lossless conversion

A well-formed document may still lose information when mapped to JSON. Check a fixture containing CDATA, repeated elements, attributes and mixed text before using the output. Formalint keeps CDATA characters and repeated values, but its object view cannot retain the order of text interleaved with child elements. Review the XML to JSON mapping and expected output; preserve the original document when order, namespaces or signatures are part of the contract.

Recheck after editing a failed document

The XML tool clears previous output when input changes or parsing fails. Correct the first reported error, then run Validate or Format again before copying or downloading. This prevents a valid result from an earlier document being mistaken for the current payload. See the XML result and download test sequence for a reproducible example.