XML URL Decode

Getting the document back

A request in a log, a callback parameter, a link from a bug report — somewhere in it is a few hundred characters starting %3C%3Fxml and you need to see the document. Paste it above and it comes back indented, with the element count beside it so you can tell at a glance whether the whole thing arrived.

The re-indenting is not decoration. Whatever built the URL had the same reason to strip the whitespace that our encoder does, so what comes out of a query string is almost always one very long line. Handing that back unchanged would be technically correct and practically useless.

The important rule on this page is decode exactly once. XML carries its own escaping underneath the URL's: an ampersand in text is written & because XML requires it, and percent-encoding then escapes that entity in turn. Unwinding the URL layer gives you & back, and that is the finish line. Going one step further leaves a bare ampersand, and the document stops being well-formed.

So the output is checked. If what came out will not parse you get the browser's own message with its line and column — and the text is still shown, because where it stops is usually the diagnosis. A document that ends mid-tag was truncated by something between you and the server, and no amount of decoding will recover the rest.

How to use it

1. Paste the parameter value – The value alone, not the whole URL — everything after the = and before the next &. A whole URL will decode fine but is not an XML document, and the page will say so rather than pretend.
2. Read the element count – It counts elements at every depth. If a document that should carry forty records reports six, you are looking at a truncated payload rather than a decoding problem, and the fix is at the other end.
3. Stop at one decode – Entities like & and < in the output are correct and belong to the XML. Decoding again to "clean them up" produces a document a parser will refuse.
4. Check for the double-encoding bar – An amber bar naming a %25 sequence is different — that really is two layers of percent-encoding, and the output needs decoding once more. %25 is the signature; %26amp%3B is not.
5. Take it on to another tool – Once it is readable, XML to JSON or XML to Table will usually get you to the answer faster than reading tags, and XML Validator gives a fuller account of a document that will not parse.

When a decoded document looks right but a downstream parser still rejects it, check the very start for a byte order mark or a stray space before the declaration. <?xml …?> has to be the first thing in the file, and a single leading character makes it invalid — which reads as an encoding bug and is really a whitespace one.

One layer, not two

The output that makes people reach for a second decode, and what happens if they do. There are two independent escaping layers stacked over a single ampersand — the XML entity, and the percent-encoding on top of it. This page removes the outer one, which is exactly the right amount:

%3Capn%3Einternet%26amp%3Bmms%3C%2Fapn%3E

# two layers of escaping,
# stacked over one &

# this page — one layer off
<apn>internet&amp;mms</apn>
# well-formed. stop here.

# one layer too far:
<apn>internet&mms</apn>
# error on line 1 at column 21:
# xmlParseEntityRef: no name

When this comes up

Reading a SOAP request out of a log

Access logs record the full request line, so a document sent on a GET is sitting there percent-encoded. Pulling it out is often the whole investigation, particularly when the question is what a caller actually sent rather than what their documentation says they send.

Debugging a SAML or federation redirect

These flows nest parameters inside parameters, so a value can genuinely arrive encoded twice through no fault of your own. The %25 flag here distinguishes that from the entity case in one glance, which saves a surprising amount of arguing.

Reproducing a failing request

Decode, edit one field in the readable document, then re-encode with XML URL Encode. Editing percent-escapes directly is possible and is how a stray %3 gets left behind.

Checking whether a payload was truncated

The element count and the point where the text stops answer this immediately. A URL cut at a round number of characters is a proxy or a request-line limit, not anything wrong with the encoding, and that distinction decides who fixes it.

What this page does

• Decodes and re-indents in one step, so a compacted document is readable rather than merely decoded.
• Parses the result and shows the browser's own error, with line and column, when it will not.
• Still shows the decoded text when it is not valid XML — where it stops is usually the clue.
• Distinguishes genuine double encoding (%25) from the XML entity case (%26amp%3B), which look alike and are not.
• Names the exact character when an escape is broken, rather than the single generic error the browser built-in throws.
• Counts elements at every depth, which is the quickest check that a payload arrived whole.
• Runs entirely in your browser. Nothing you paste is sent anywhere.

Questions people actually ask

My output still has & in it. Do I decode again?

No — that is the XML doing its job. An ampersand inside element text has to be written as & for the document to be well-formed. Turning it into a bare & gives you something Chromium rejects with error on line 1 at column 21: xmlParseEntityRef: no name. If a downstream tool needs the raw character it will unescape the entity itself when it parses.

Then what does double encoding look like?

It shows up as %25 — the escape for a percent sign — immediately followed by what looks like another escape, so %20 arrives as %2520. That gets an amber bar here and genuinely does need a second decode. OWASP has a good write-up of why it also matters for security, not just correctness.

Does re-indenting change my document?

Only where whitespace was not content. Mixed content — text sitting beside an element, as in <p>Hello <b>world</b></p> — is emitted in one piece rather than split across lines, and anything under xml:space="preserve" is left exactly as it is. The re-indented document is then parsed again and compared against the original; if they differ at all, you get the original.

Why does it say the XML is not well-formed when it looks fine?

Read the line and column in the bar — it comes from the parser, not from us. The usual causes are a truncated payload (the document simply ends), a bare ampersand where an entity was expected, or an unclosed tag. Note also that <?xml …?> must be the very first thing in the document, so a single leading space is enough to fail it.

What about the plus sign?

Same rule as everywhere else: decodeURIComponent reads + as a plus, while a form writes a space as +. It bites less often on XML than on JSON, because XML is usually built by a serialiser rather than a form — but the switch is there, and the note under the output says which reading was applied. The WHATWG URL Standard is where that rule is actually written down.

Can it handle namespaces and CDATA?

Yes to both. Namespace declarations are ordinary attributes, and a CDATA section is re-emitted verbatim rather than unwrapped — unwrapping it would turn its contents into real markup, which is corruption of a different kind. That is the same rule the XML Formatter follows.

Related tools

References

• XML 1.0 — Predefined Entities – The five entities, and when they are required
• MDN — decodeURIComponent() – And the single error it throws for every fault
• RFC 3986 §2.4 — When to Encode or Decode – On decoding exactly once, and why twice corrupts