BrowserTools
Advertisement
Home / Validators / XML Validator & Formatter

XML Validator & Formatter

Validate and pretty-print XML in your browser using the DOMParser.

Loading XML Validator & Formatter… If nothing happens, please enable JavaScript.

Frequently asked questions

Is my XML sent to a server?
No. Parsing and formatting happen entirely in your browser using the built-in DOMParser API, which is part of the Web platform and runs locally on your device. Your XML content is never transmitted over the network, making this tool safe for confidential configuration files, internal schemas, or proprietary data formats.
What is the difference between well-formed XML and valid XML?
A well-formed XML document follows the basic syntax rules of the XML specification: it has a single root element, all tags are properly nested and closed, attribute values are quoted, and reserved characters are escaped with entity references. A valid XML document additionally conforms to a declared schema — a DTD (Document Type Definition) or XSD (XML Schema Definition) — which constrains which elements and attributes are allowed and in what order. This tool checks only well-formedness.
When would I need to validate XML in practice?
Common scenarios include debugging SOAP web service requests and responses, inspecting Maven or Gradle build files, examining Android resource files, reviewing RSS/Atom feed markup, checking SVG image files, formatting Spring Framework bean configurations, and validating HL7 or FHIR messages in healthcare integrations. Any time a tool or library reports an XML parse error, pasting the content here quickly reveals the problematic line.
How is XML different from HTML?
HTML is designed to be resilient to errors — browsers will render a page even with unclosed tags, missing quotes, and overlapping elements, applying complex error-recovery rules. XML is strict: a single syntax error makes the entire document invalid and it must not be processed further. HTML uses a fixed vocabulary of elements defined by the HTML specification; XML allows any tag names defined by the document author or its governing schema.
Does this tool validate against an XSD or DTD schema?
Not currently. This tool checks only XML well-formedness — correct syntax — using the browser's DOMParser. Schema validation against XSD (XML Schema Definition) or DTD (Document Type Definition) is a more complex operation that requires a specialised validator. For XSD validation, command-line tools like xmllint (libxml2) or online XSD validators that accept both the schema and document are better suited.
What is the maximum size of XML I can validate?
There is no hard-coded limit, but the browser's available memory and the DOMParser's performance impose practical constraints. Documents up to a few megabytes parse and format in milliseconds. Very large XML files — hundreds of megabytes, such as database exports or large SOAP responses — may cause the browser tab to become slow or unresponsive. For large-scale XML processing, command-line tools like xmllint or Saxon are more appropriate.
Does the tool work with XML namespaces?
Yes. The DOMParser fully supports XML namespaces as defined by the Namespaces in XML specification. Namespace prefixes (xmlns:ns="...") and default namespaces (xmlns="...") are parsed and preserved in the formatted output. Namespace-aware elements and attributes are displayed with their prefixes intact.
Can I use this tool to format SVG files?
Yes. SVG (Scalable Vector Graphics) files are well-formed XML documents and can be validated and formatted by this tool. Pasting an SVG and pretty-printing it is a quick way to inspect its structure, check for malformed paths, or review embedded metadata. Note that the formatter re-serialises the XML, which may change the order of attributes (though this does not affect rendering).
What are XML entities, and do I need to escape characters in my content?
XML defines five predefined entity references for characters that have special meaning in XML syntax: &amp;amp; for &, &amp;lt; for <, &amp;gt; for >, &amp;apos; for ', and &amp;quot; for ". These must be used whenever the literal character appears in element text content or attribute values. Using a raw & or < inside content will cause a well-formedness error. In CDATA sections (wrapped in <![CDATA[...]]>) the content is treated as literal text and no escaping is needed.
What is a common mistake that makes XML invalid?
The most frequent mistake is using an unescaped ampersand (&) in text content — for example in a URL like href="https://example.com/page?a=1&b=2", where & must be written as &amp;. Other common errors include self-closing tags written without the trailing slash (&lt;br&gt; instead of &lt;br /&gt;), mismatched tag casing (&lt;Item&gt; closed as &lt;/item&gt;), and missing quotes around attribute values. Unlike HTML parsers, XML parsers will refuse to continue after any of these errors.

About XML Validator & Formatter

XML (eXtensible Markup Language) is a text-based format for storing and transporting structured data. Developed by the W3C XML Working Group and first released as a recommendation in 1998, XML was designed to be simultaneously human-readable and machine-parseable, self-describing, and extensible — meaning developers could define their own tags and document structures rather than being limited to a fixed vocabulary. XML grew directly from SGML (Standard Generalised Markup Language), the complex ISO standard used for technical documentation, but stripped away most of SGML's complexity to produce something that could be implemented in a weekend.

Despite JSON's rise to dominance for web APIs, XML remains deeply embedded in enterprise and system-level software. SOAP web services, used heavily in banking, healthcare (HL7 FHIR), and government systems, transmit XML messages. Microsoft Office documents (.docx, .xlsx) are ZIP archives of XML files. Android layout files and Maven project descriptors are XML. RSS and Atom feeds are XML. SVG images are XML. Configuration systems like Spring Framework, Hibernate, and Ant build files use XML extensively. Any developer working with legacy integrations, enterprise systems, or document formats will encounter XML regularly.

This tool validates and formats XML entirely inside your browser using the browser's built-in DOMParser API — the same engine that renders HTML pages. It parses your input and reports the first well-formedness error with the line and column number so you can pinpoint problems instantly. Valid XML is then re-serialised with consistent indentation to produce a clean, readable output. Because all processing happens locally, your XML documents — which may contain proprietary schemas, credentials in configuration files, or sensitive business data — are never uploaded to any server.

XML is stricter than HTML in important ways that trip up developers new to the format. Every element must be properly closed (unlike HTML, which tolerates unclosed tags). Attribute values must always be quoted. The document must have exactly one root element. The five predefined entity references (&amp;, &lt;, &gt;, &apos;, &quot;) must be used for the corresponding literal characters inside text and attribute values. XML is also case-sensitive: &lt;Tag&gt; and &lt;tag&gt; are different elements. Well-formedness (correct syntax) is a separate concept from validity (conformance to a schema such as XSD or DTD), and this tool checks only the former.

XML and the quest for a universal document format

XML grew out of a decade-long effort to tame SGML (Standard Generalised Markup Language), a powerful but enormously complex ISO standard originally designed for technical documentation at the US Department of Defense. SGML was so intricate that only specialised software could process it. In 1996, a W3C working group led by Jon Bosak set out to create a simplified 10 % of SGML that would cover 90 % of the use cases — and do so in a form that could be implemented in a weekend rather than years. XML 1.0 became a W3C Recommendation on February 10, 1998.

The late 1990s and early 2000s were peak XML enthusiasm. Technologists envisioned XML as the universal glue of the internet: documents, data, configuration, messaging, and even programming would all be XML. Web services would use SOAP (Simple Object Access Protocol) envelopes of XML. Applications would describe their interfaces in WSDL (Web Services Description Language), itself an XML dialect. The 'angle-bracket tax' — the verbosity of XML syntax — was seen as a worthwhile price for universal interoperability.

The backlash came with JSON's rise in the mid-2000s. JSON's compactness and direct mapping to JavaScript objects made it dramatically simpler for web API use cases, and it rapidly displaced XML in that domain. Yet XML never disappeared. It remains the dominant format in enterprise integration, document formats (ODF, OOXML), configuration systems, and anywhere that schemas, namespaces, and the ability to mix document and data are genuinely valuable. The W3C's XSLT transformation language and XPath query language — both XML-based — have no real JSON equivalents for complex document transformation tasks.

Advertisement