YAML URL Decode

Getting the document back

A YAML fragment came back out of a URL and you need to know two things: what it says, and whether it is still the same shape it went in as. This page answers both — it decodes the escapes, then loads the result and tells you how many documents it found.

The loading step is not a formality here. In JSON or XML a stray whitespace change is invisible to the parser; in YAML it is the parser's entire input. A single %20 lost from the start of a line moves that line up a level, and the result is very often still valid YAML — just a different document. Nothing errors. That is the failure this page exists to catch, and it is why the output is checked rather than simply displayed.

There is deliberately no re-indent button, which is the opposite of the XML decoder. Adding whitespace back into XML is cosmetic; adding it to YAML rewrites the document. What comes out here is exactly what was in the URL, and if that is one long line then one long line is the truth about what you were sent.

Everything else works as on the other decoders: %25 sequences get flagged as genuine double encoding, a broken escape is reported with the character position rather than the single unhelpful error decodeURIComponent throws for four different faults, and long integers are left exactly as they were written.

How to use it

1. Paste the parameter value – The value only, not the whole URL. Look for %0A — a run of them is the signature of a block-style YAML document, and their absence in something that should be multi-line is worth noticing straight away.
2. Check the document count – One is what you usually expect. More means the payload carried --- separators, which is normal for Kubernetes manifests; fewer than you expected means separators were lost and several documents have quietly merged into one.
3. Read the output as structure, not text – The question is whether the indentation is what it should be. If a key has moved a level, the document will often still load — so comparing against what you expected is the check, not the absence of an error.
4. Act on a tab warning immediately – A tab in the indentation makes the document invalid outright, and it is invisible in an editor. The line number is in the bar. This is the single most common YAML fault, so it gets its own message rather than a generic parse error.
5. Take it on to another tool – YAML to JSON is the fastest way to confirm the structure is what you think it is, since a misplaced key is obvious in JSON and easy to miss in YAML. YAML Validator gives a fuller account when something will not load.

If the decoded document loads but behaves differently from the original, diff the two through YAML to JSON rather than reading the YAML side by side. A key that has shifted one level looks almost identical in YAML and is unmissable in JSON — that is the trick that turns a twenty-minute stare into a five-second check.

Why a single lost space matters here

This is what makes YAML different from every other format on this site. In JSON or XML, whitespace between tokens is meaningless and losing some costs you nothing. In YAML the leading whitespace is the structure, so a payload that lost one %20 does not fail — it succeeds, and means something else:

%23%20SIM%20provisioning…%0A
subscriber%3A%0A%20%20msisdn…

# %0A is a line break
# %20 is a space — and in
# YAML those are structure

# decoded — and loaded, to
# prove the shape survived
# SIM provisioning request
subscriber:
  msisdn: "447700900112"
  iccid: 8901240544102066246

# one %20 lost and this is
# a different document, or
# not a document at all

When this comes up

Reading a config override out of a job URL

CI systems pass YAML fragments as parameters, and when a run behaves oddly the first question is what it was actually given. Decoding the parameter answers that directly, rather than inferring it from the run log.

Checking a manifest survived being passed around

A Kubernetes manifest that has been through a form, a redirect and a shell has had several opportunities to lose whitespace. The document count and the indentation in the output tell you whether it arrived intact, which a diff of the encoded strings would not.

Reproducing a whitespace bug from a bug report

Chat clients and issue trackers normalise whitespace, so a YAML file pasted into one is not the file that broke. If the reporter sends it URL-encoded it arrives byte for byte, and this is where you unpack it.

Confirming a tab is the culprit

A config that fails on one machine and works on another is very often a tab that one editor inserted and another converted. Decoding here names the line, which is faster than turning on whitespace rendering and hunting for it.

What this page does

• Decodes the escapes and then loads the result, so you learn whether the structure survived rather than only what the text says.
• Counts the documents, which is how you notice lost --- separators.
• Names tabs specifically, with a line number — the commonest YAML fault and the hardest to see.
• Hands back exactly what was in the URL. No re-indenting, because in YAML that would change the meaning.
• Flags genuine double encoding (%25) and reports a broken escape with its character position.
• Keeps long integers exact, so a 19-digit identifier is not rounded on the way through.
• Runs entirely in your browser. Nothing you paste is sent anywhere.

Questions people actually ask

Why does the XML decoder re-indent and this one does not?

Because indentation means nothing in XML and everything in YAML. Re-indenting an XML document changes how it looks; re-indenting a YAML document changes what it says. A decoder that quietly restructured your config would be worse than one that hands back a long line, so this page hands back exactly what it was given.

My decoded YAML loads but the values are nested wrongly.

That is the whitespace failure rather than an encoding one — almost certainly a %20 lost before the document reached you, which moved a key up or down a level. It is the nastiest case precisely because the result is still valid. Run both the original and the decoded version through YAML to JSON and the difference will be obvious.

What is %0A?

The escape for a newline. A URL cannot carry a raw line break, so a block-style document has one %0A per line. If a multi-line document arrives with none, it was either flattened before it was encoded or you are looking at only part of it.

It says there is a tab. Where?

The bar gives the line number. You will not see the tab, which is the whole problem — a tab and four spaces are identical on screen. YAML forbids tabs in indentation with no exceptions, so one anywhere in the leading whitespace is enough to fail the document.

The output has %25 in it and an amber bar. What now?

That is real double encoding — the value passed through two encoders, so %20 arrived as %2520. Decode the output once more to reach the actual document. It is worth finding where the second encoder is, because it causes security problems as well as broken payloads.

Does the plus sign matter for YAML?

Less often than for JSON, because YAML payloads are usually built by a serialiser rather than a form — but it still applies, and the switch is above the input. Where it bites is a value like a phone number or a Base64 blob inside the document: reading a genuine plus as a space corrupts it silently, which is why the note under the output says which reading was used.

Related tools

References

• YAML 1.2.2 — Indentation Spaces – Why a lost space changes the document
• WHATWG URL — form-urlencoded parsing – Where the plus-sign rule is written down
• RFC 3986 §2.4 — When to Encode or Decode – On decoding exactly once