XML Formatter

Only into a formatter that works in your browser. XML carries invoices, SOAP payloads, insurance and medical records and full ERP exports, which is exactly the material that must not land on an unknown server. Formatting runs here as JavaScript in your tab, with nothing uploaded, logged or stored, and it keeps working offline. For any other tool, open the Network tab in devtools and format a harmless document first: if a request goes out, so does everything you paste afterwards.

Pretty-print it, which means a line break after each tag and children indented one level deeper than their parent. Machine-generated XML arrives as one long line because whitespace costs bytes on the wire; the structure is intact, it is just not laid out for eyes. In an editor: VS Code formats with Shift+Alt+F once the XML extension is installed, Notepad++ needs the XML Tools plugin and its "Pretty print" entry, and on the command line xmllint --format file.xml does it without installing anything on macOS or Linux. Pasting into a browser tool is the quickest route when the XML is in your clipboard, for example a SOAP body copied out of a log.

With a validator that you feed both files, because well-formedness and schema validity are different checks. Well-formedness (every tag closed and nested, one root, attributes quoted, & escaped) is what a formatter can tell you and what the VALID stat above reports. Schema validation additionally checks that the elements are the ones the XSD allows, in the right order, with the right types, and it needs the .xsd file: xmllint --schema schema.xsd file.xml --noout on the command line, the XML Tools plugin in Notepad++, or the built-in validation in an IDE like IntelliJ or Visual Studio. A document can be perfectly well-formed and still be rejected by the receiving system, which is the distinction most "xml validator online" results skip over.

A raw ampersand appears in text or an attribute, usually in a URL like ?page=2&size=10. In XML, & always starts an entity reference, so a bare one is a syntax error. Write &amp; instead; the same goes for < in text, which must be &lt;. This is the single most common well-formedness error in hand-edited XML.

For element structure, attributes, comments and CDATA: no, everything comes through unchanged and in order. What does change is whitespace between and around tags, that is what pretty-printing is. In documents where whitespace inside mixed content is significant (an XHTML paragraph, a document format), reindenting can alter rendering, so treat pretty-printing as a tool for data XML, not typeset documents.

HTML is a specific vocabulary with defined tags and forgiving parsers; XML is a generic syntax where you define the tags and parsers are strict by design. HTML browsers repair broken markup silently, an XML parser must stop at the first well-formedness error. HTML also allows unclosed tags like <br> and unquoted attributes; XML allows neither.

A CDATA section (<![CDATA[ ... ]]>) tells the parser to treat its content as literal text, so < > & lose their special meaning. It exists for embedding code, markup samples or scripts inside XML without escaping every character. You rarely need to write it yourself; where you meet it is feeds and legacy SOAP. This formatter passes CDATA sections through byte-identical, many online tools silently unwrap or mangle them.

Almost. <!-- comment --> can sit between elements anywhere in the document, including before or after the root element, but not inside a tag and not inside another comment, and the sequence -- is forbidden within comment text. This formatter keeps comments exactly where they are, which is worth checking in any formatter you use: tools built on parse-to-object-and-rebuild typically drop them.

It is optional for XML 1.0 documents in UTF-8 or UTF-16, and required if the version is not 1.0 or the encoding is anything else. Leaving it in costs nothing and removes guesswork for consumers, so the common advice is to keep it. This tool preserves the declaration if your input has one and does not invent one if it does not.

The spec defines a document as one element containing everything else; two siblings at the top level make the document not well-formed. The practical reason is that a parser needs a single tree to hand back. If you have a series of fragments (log entries, records), wrap them in a container element or process them as separate documents.

Both are equivalent to an XML parser, byte-for-byte different but semantically identical. <tag/> is shorter and signals "intentionally empty" at a glance; the long form sometimes survives because a serialiser wrote it. The --self-close option here rewrites empty elements to the short form. The one place to be careful is XHTML served as text/html, where browsers mistreat self-closed versions of tags like <script/>.

The parser reached the end of the document while still expecting markup, so the file is truncated, empty, or has a tag that was never closed. Three causes cover almost all of it: a download or export that stopped early, a response that was empty because the server returned an error body of zero length, and a stray character before the XML declaration, which must be the very first byte of the file. A UTF-8 byte order mark or a blank line ahead of it produces the equally common "XML declaration allowed only at the start of the document". Check the file size first, then the last line of the document, then the first byte.

Not with a normal editor, because loading a 500 MB document builds a tree several times its size in memory. Read it with a streaming parser instead: xmllint --stream validates without holding the file, xmlstarlet extracts specific paths, and SAX or iterparse in Python walks the records one at a time so memory stays flat. For a quick look at the structure, head -c 100000 file.xml piped into a formatter shows you the first records, which is usually all you need to write the extraction. A browser tool copes with a few dozen megabytes; beyond that the tab is doing exactly the work you should be avoiding.