Base64 to XML

Read the SAML message or signed document inside the blob

Base64 Input

Decoded XML

Success
Warning

Where XML-in-Base64 comes from

XML and transport do not get on. An XML document is full of angle brackets, quotes and newlines, so putting one inside an HTML form field, a URL, or another XML document means escaping it or wrapping it. Base64 is the wrapping option, and single sign-on leans on it heavily: a SAMLResponse arrives as one enormous form field of Base64, and reading it is the first step in working out why a login failed.

Paste the blob and the XML appears on the right, exactly as it was encoded. Everything happens in this tab — worth stating plainly, because a SAML assertion contains someone's identity and often their group memberships.

There is a wrinkle in SAML specifically that costs people an afternoon, usually more than once. The SAML 2.0 bindings specification defines two ways to carry a message. The HTTP-POST binding Base64-encodes the XML directly. The HTTP-Redirect binding compresses it with raw DEFLATE first, then encodes. So one blob decodes to readable XML and the next decodes to what looks like line noise — same protocol, same day, different binding. Nothing about the string tells you which you have.

This page tries inflating whenever the decoded bytes are not text, so a SAMLRequest lifted straight out of a redirect URL opens like any other. When that happens it says so, because knowing your message came through the redirect binding is often the actual answer to whatever you were debugging.

Decoding a message

  1. Paste the encoded XML – A SAMLResponse field, a SAMLRequest query parameter, or any Base64 holding a document. URL-encoded input needs one step first — see the tip below. Sample loads a small SAML response.
  2. Read the XML on the right – Shown byte for byte as it was encoded, with no reindenting. That is deliberate, and the reason is in the FAQ: reformatting a signed document breaks the signature.
  3. Watch for the two notes – One tells you the payload had to be inflated, meaning it came from the HTTP-Redirect binding. The other reports a well-formedness error if the XML does not parse — truncation partway through a long assertion is by far the most common cause.
  4. Take it further – Copy it, or move on to XML Formatter to indent it for reading, XML to JSON to work with it programmatically, or XML to Table if it holds a list of repeated elements.

If you pulled the string out of a browser address bar it is probably URL-encoded as well as Base64 — %2B where a + should be, %3D for =. Run it through decodeURIComponent() in the console first, otherwise the percent signs come back as invalid characters. Redirect-binding parameters are almost always in that state.

Two SAML messages that look nothing alike

Both of these carry XML. The first came through the HTTP-POST binding and decodes straight to text — you can even read PHNhbWxw as <samlp once you have seen it a few times. The second is the same kind of document through the HTTP-Redirect binding, DEFLATE-compressed first, which is why it decodes to bytes rather than characters.

POST binding vs Redirect binding inflated automatically
encoded messageSame protocol, two encodings
# HTTP-POST binding — plain base64
PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNh
bWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6
U0FNTDoyLjA6cHJvdG9jb2wiLi4u

# HTTP-Redirect binding — DEFLATE first
VY7BCgIhFEV/RfwAnVw+VBhoM1Cbgr
Zh8mAG1Gc+hfn8qDa1vJzD4VoOOVWY
decoded.xmlBytes untouched
<samlp:Response ID="_8f2a"
                Version="2.0">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Assertion>
    <saml:NameID>rosalind.franklin@…</saml:NameID>
  </saml:Assertion>
</samlp:Response>

When this is what you need

Debugging a single sign-on failure

The identity provider says it sent the right thing, the service provider says it did not receive it, and the only artefact anyone has is a Base64 field from a browser trace. Decoding it settles the argument: you can see the Destination, the Audience, the NotOnOrAfter and which attributes were actually included. Clock skew and a stale AssertionConsumerServiceURL account for a good share of these.

Checking what attributes an IdP releases

Before wiring up an application you usually want to know whether the assertion carries the email, the display name and the group memberships, or only an opaque identifier. Decoding one real assertion answers that faster than reading the metadata.

Opening an embedded document from an API

Financial and healthcare interfaces routinely put an XML document inside a JSON field as Base64 — an ISO 20022 payment message, an HL7 CDA, a signed invoice. This is how you look inside one without writing a script.

Confirming something was not truncated

Long assertions get cut off by a field length limit or a log rotation more often than you would expect. The well-formedness check catches that immediately — a document that ends mid-element is unmistakable once a parser looks at it.

What it handles

  • DEFLATE-compressed payloads. Raw deflate, zlib and gzip are each attempted when the bytes are not text, so redirect-binding SAML opens instead of appearing corrupt.
  • URL-safe and unpadded input, plus MIME line wrapping and data: prefixes — all stripped and reported rather than rejected.
  • Well-formedness checking. The decoded document goes through the browser's own parser, and the first error is shown with the text still visible above it.
  • Nothing is reformatted. The output is the bytes that were encoded, which is the only safe behaviour for a signed document.
  • Binary payloads are identified. If it is a PKCS#7 blob or an image rather than a document, the page says so and gives you the size instead of printing noise.
  • It stays in the browser. No assertion, token or identity is transmitted anywhere.

Questions that come up

Why is the output not indented?

Because indenting it would break the thing you are most likely holding. XML Signature signs a canonicalised byte sequence, and adding whitespace between elements changes those bytes — so a reformatted assertion still looks correct and no longer verifies. If you want it readable, copy it into XML Formatter, having made that decision knowingly.

My SAMLRequest decodes to gibberish. Is it broken?

Almost certainly not. The HTTP-Redirect binding applies raw DEFLATE before Base64, so the decoded bytes are compressed rather than textual. This page inflates them automatically and tells you it did. If you are decoding elsewhere, that is the missing step — and note it is raw deflate with no zlib header, which is why a plain zlib.inflate often fails where inflateRaw works.

Does decoding tell me whether the assertion is valid?

No. Decoding shows you the content; validity depends on the signature, the certificate that signed it, the time window and the audience. Reading the XML is how you form a hypothesis, not how you confirm one. Verification belongs in your SAML library, which will also check things the human eye skips.

It says the payload is not well-formed. What now?

Look at where the text stops. A document that ends part-way through an element was truncated in transit — a field length limit, a log line cut short, or a copy that missed the last screenful. If instead it ends cleanly but the parser complains about an entity or a stray &, the document was hand-edited after it was produced.

Can I encode in the other direction?

XML to Base64 does that, with standard, URL-safe or MIME-wrapped output. For other payload types there are Base64 to JSON and Base64 to Text.

What if the decoded XML contains CDATA?

It is shown exactly as encoded, CDATA sections and all. That matters because CDATA is where converters most often lose data — a parser collecting only text nodes drops it entirely, since a CDATA section is node type 4 and not the 3 that filter is looking for. Nothing is being converted here, so nothing can be lost.

Related tools

XML to Base64The other directionXML FormatterIndent it once decodedXML to JSONWork with it as dataXML ValidatorCheck it properlyBase64 to JSONWhen the payload is JSONBase64 to TextWhen it is neither

Worth reading