KeroTools

XML Formatter and Validator

Format, validate, or minify XML instantly — results update live as you type, right in your browser.

Input
0 chars
Output

Your document stays on your device

Nothing to delete afterwards

Safe for regulated documents

Works in every modern browser

How it works

  1. 1

    Paste your XML

    A configuration file, an API response, an invoice, a feed or an export you need to read.

  2. 2

    Format or minify

    Indent it to read it, or strip it back down — with the warnings shown either way.

  3. 3

    Copy the result

    Take it into an editor, a ticket, a test fixture or a document you are about to send.

Why use this tool

Told when formatting changes data

Indenting an element that holds text alters that text, and you are warned before it happens rather than after.

Namespace prefixes preserved

Prefixes are left exactly as written, so the XPath expressions and stylesheets that reference them keep working.

External entities never resolved

No file is read and no URL is fetched, which is the one property an XML tool most needs to have.

Expansion bombs refused

A small document that expands into gigabytes is detected and rejected instead of freezing the tab.

Declaration and encoding kept

The XML declaration, its encoding attribute and any byte order mark survive the round trip unchanged.

Nothing leaves the browser

Invoices, SOAP payloads and identity assertions are processed on this page and uploaded nowhere.

Indenting XML is not cosmetic — whitespace inside an element is data

This is the fact that separates XML formatting from JSON formatting, and almost every surprise in this subject follows from it. In JSON, the whitespace between tokens is outside the data model entirely: reformat a document and every value your parser reads is identical. XML has no such guarantee. The content of an element is a text node, and whitespace is part of that node unless something explicitly says otherwise. Turn `<name>Ali</name>` into an indented form with the text on its own line and the element no longer contains `Ali` — it contains a newline, two spaces, `Ali`, another newline and more spaces. Most application code hides this by trimming on the way out, which is exactly why it goes unnoticed until it matters: a value compared against a database, a checksum, a signature. The XML specification does provide `xml:space="preserve"` to declare that whitespace is significant, and a schema can mark an element as whitespace-insensitive, but a formatter looking at a document alone knows neither. It has to warn instead of assume, and that is what this one does.

Reformatting a signed document invalidates the signature, and that is by design

The consequence above becomes concrete the moment a document is signed. XML digital signatures do not sign the file — they sign a canonical form of the document tree, produced by a normalisation step defined in the Canonical XML specification. That step fixes attribute order, namespace declarations and certain whitespace so that two documents which mean the same thing hash the same way. What it does not do is forgive whitespace you added inside an element’s content, because as far as the model is concerned that is not formatting, it is a change to the data. So a signed invoice, a SAML assertion or a SOAP message that has been prettified is no longer valid, and the failure is total: verification does not report a small discrepancy, it reports that the signature does not match. The rule to carry away is that a signed document is a binary artefact wearing a text costume. Read it formatted if you like, but send the bytes you received.

The namespace prefix is not the name — the URI is

Namespaces are where XML’s design most often surprises people coming from JSON, and where a careless formatter does real damage. A prefix like `soap:` or `ns2:` is a local abbreviation with no meaning of its own; what identifies an element is the URI that prefix is bound to. Two documents using `a:Body` and `env:Body` are identical if both prefixes are bound to the same namespace URI, and two documents both using `ns:Item` are unrelated if the URIs differ. That is why a tool that helpfully renames prefixes to something tidier produces a document that is technically equivalent and practically broken: every XPath expression, XSLT template and hard-coded selector in your codebase refers to the prefix, not the URI, because that is what people write. Default namespaces add a second trap, since an unprefixed element inside `xmlns="…"` is in that namespace while an unprefixed attribute is in no namespace at all. This tool changes no prefix and moves no declaration.

Entity expansion is why an XML parser must be told what not to do

XML lets a document define its own entities, and lets one entity refer to another. That single feature produces the best-known denial-of-service in the format’s history: define an entity as ten copies of another entity, nest that ten deep, and a document of a few hundred bytes expands to a billion characters. It has a name — the billion laughs attack — and it works on any parser that expands entities without a budget. The sharper problem is external entities, which let a document declare that an entity’s value should be read from somewhere: `SYSTEM "file:///etc/passwd"` reads a local file, and an `http://` URL turns the parser into a request client that will happily reach into a private network on an attacker’s behalf. That is XXE, and it has been used to read credentials off production servers for years. The defence is not clever parsing, it is refusal: a document processor that never resolves an external entity cannot be made to fetch anything. This tool resolves none, and caps expansion, which is why a hostile document here is merely rejected.

The declaration, the encoding and the chicken-and-egg problem

The first line of an XML document usually declares its own encoding, which raises an obvious question: how does the parser read that line before it knows the encoding? The answer is a bootstrap. A parser inspects the first few bytes, uses a byte order mark if one is present, otherwise assumes a family of encodings in which the ASCII characters `<?xml` are recognisable, reads the declaration and then switches to whatever it says. This works, but it leaves several ways to break a file with an edit that looks harmless. Saving a document as UTF-8 while the declaration still says `ISO-8859-1` produces a file that is wrong in a way no editor will show you. Adding a byte order mark to a document declared as UTF-8 is legal but breaks strict consumers that expect the first byte to be `<`. Putting anything at all — even a blank line — before the declaration is a fatal error, because the declaration must be the very first thing in the file. This tool leaves the declaration and any byte order mark exactly as it found them.

What is actually inside the XML people need to format

It is worth naming the documents, because the list explains the caution. XML is where the regulated parts of the software world live: electronic invoices submitted to a tax authority, SOAP payloads moving between banks, SAML assertions that are literally someone’s identity in transit, health records, court filings, payroll exports, product feeds with unreleased prices. When someone reaches for a formatter, it is almost always because one of those documents failed and they need to read it — which means the example in their clipboard is a real one, complete with the customer’s tax number and the assertion’s subject. Pasting it into a hosted formatter uploads exactly that, and a SAML assertion in particular is a bearer credential for as long as it remains valid. This page parses and prints the document in JavaScript and makes no request while doing it; the network panel of your developer tools will show the same.

Common mistakes to avoid

  • Assuming XML formatting is safe the way JSON formatting is. Whitespace inside an element is part of its text node, so indenting a document changes the values a parser reads back.
  • Prettifying a signed document. Signatures cover a canonical form of the tree, and added whitespace inside element content is a data change — verification fails outright.
  • Letting a tool rename namespace prefixes. The URI is the identity, but every XPath and XSLT in your codebase refers to the prefix, so a technically equivalent document breaks in practice.
  • Parsing untrusted XML with external entities enabled. `SYSTEM "file:///…"` reads local files and an http URL makes the parser fetch on an attacker’s behalf — this is XXE.
  • Changing the encoding without changing the declaration. Saving as UTF-8 while the first line still says ISO-8859-1 produces a file no editor will show you as wrong.

How it compares

AspectThis toolOnline formattersAn editor plugin
Document sent to a serverNeverUsually yesNo
Warns when indenting changes dataYesNoRarely
Resolves external entitiesNeverSometimesConfigurable
Preserves namespace prefixesAlwaysUsuallyUsually
Keeps declaration and byte order markYesVariesUsually
PriceFreeFree / paid tiersFree

Features

Formatting and minification

Both directions, with the indent width under your control and tabs available where a project requires them.

Well-formedness checking

Unbalanced tags, stray ampersands and invalid names are reported with the line and column they occur on.

Whitespace-safety warnings

Elements holding mixed content or significant text are flagged before indentation would rewrite them.

Attribute order untouched

Attributes stay in document order, since some consumers and some signatures depend on it.

CDATA and comments preserved

Sections are kept verbatim, including the content that would otherwise need escaping.

Large documents supported

A multi-megabyte export formats without an upload or a size ceiling.

Nothing to install

No build tool, no runtime, no dependencies — it runs in the web page.

Arabic and RTL ready

The full interface in eight languages, including right-to-left Arabic.

Secure by default

Served over HTTPS, with no content tracking and no third-party upload.

Who uses it

Integration developers

Reading a SOAP response that arrived on a single unbroken line.

Finance and billing teams

Inspecting an electronic invoice that a tax authority rejected.

Systems administrators

Tidying a configuration file before committing it to version control.

Anyone debugging an API

Finding the one unescaped ampersand that made a document fail to parse.

Frequently Asked Questions

No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.

Yes — completely free, with no account and no limits.