XML to Base64

Why an XML document needs wrapping

An XML document is a hostile thing to embed. It is full of angle brackets, quote marks and newlines, so putting one inside an HTML form field, a JSON string, a query parameter or another XML document means either escaping every awkward character or wrapping the whole thing. Base64 is the wrapping approach, and it has the advantage that nothing between here and the destination will decide to helpfully reinterpret it.

Paste your XML on the left and take the encoded string from the right. It is all done in this tab — nothing is uploaded, which is the answer you want when the document is a signed request or holds customer data.

Single sign-on is where most people meet this, and it has a trap built into the specification. SAML 2.0 defines two ways to carry a message: the HTTP-POST binding encodes the XML directly, while the HTTP-Redirect binding compresses it with raw DEFLATE first so it fits in a URL. Send a redirect-binding request without compressing and the identity provider rejects it, usually with an error that says nothing about compression.

That is what the Deflate checkbox does. With it on, the document is compressed the way the redirect binding expects and then encoded — and because XML compresses so well, the result is normally smaller than the document you started with, rather than a third bigger.

Encoding a document

1. Paste or upload the XML – Anything: a SAML request, a config file, an SVG, a signed invoice. It is checked for well-formedness and encoded either way — a note appears if it does not parse, but nothing is blocked, because encoding a fragment on purpose is reasonable.
2. Choose the alphabet – Standard for a form field or an API. URL-safe for a query parameter, which swaps + and / for - and _. MIME wraps at 76 columns to match openssl base64.
3. Tick Deflate if this is a redirect-binding message – That is the compress-then-encode order SAML requires for SAMLRequest and SAMLResponse parameters carried in a URL. Leave it off for the POST binding and for everything that is not SAML.
4. Copy it out – The percent icon copies the result already URL-encoded, ready to append to a query string — worth using, since the + and = in standard Base64 both mean something else inside a URL.

Encode the document exactly as you intend to send it, and do the signing after encoding decisions are settled rather than before. XML Signature covers a canonicalised byte sequence, so reindenting a document — even adding a trailing newline — invalidates a signature that was already applied. The order matters, and getting it backwards produces a message that looks perfect and verifies as tampered.

The same request, with and without compression

This is the document behind the Sample button: 525 bytes of AuthnRequest. Encoded plainly it becomes 700 characters, the usual third larger. Compressed first it becomes 390 — smaller than the original XML, because markup with repeated namespace declarations is close to the ideal case for DEFLATE.

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
  ID="_7b3c9f21"
  Destination="https://idp.example.com/sso">
  <saml:Issuer>https://sp.example.com</saml:Issuer>
</samlp:AuthnRequest>

# 525 bytes (the Sample button loads this)

# plain base64 — 700 chars (+33%)
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNv
ZGluZz0iVVRGLTgiPz4KPHNhbWxwOkF1
dGhuUmVxdWVzdAogICAgeG1sbnM6c2Ft…

# deflate first — 390 chars (-26%)
fZFNS8NAEIbv-RXL3pNsUlE7NCnBUihU
kX548CLrZmoXsrtxZ1PqvxcSi61Qr-88…

Where this gets used

Building a SAML request by hand

When you are testing an integration against an identity provider and do not yet want to stand up a full service provider, hand-building an AuthnRequest and pasting the encoded form into a URL gets you an answer in minutes. The compression step is the part people miss, and it is why so many first attempts come back with an unhelpful error.

Putting XML inside JSON

A JSON string can hold XML if every quote and backslash is escaped, which is fiddly and easy to get subtly wrong. Encoding sidesteps the escaping entirely — the field becomes an ordinary opaque string. JSON Escape is the alternative if you would rather keep it human-readable in the payload.

Embedding an SVG in CSS or HTML

An SVG is XML, and a data:image/svg+xml;base64, URI puts an icon straight into a stylesheet with no extra request. Worth knowing that percent-encoding an SVG is usually smaller than Base64 for this specific case, since SVG is mostly characters that need no escaping.

Moving a document through a channel that mangles text

Email systems, older message queues and some logging pipelines rewrite line endings or strip control characters. Encoding first means what arrives is what you sent, byte for byte, which matters a great deal if the document is signed.

What it does

• Raw DEFLATE on request. The exact compression SAML's HTTP-Redirect binding specifies — no zlib header, which is the detail most hand-rolled implementations get wrong.
• UTF-8, correctly. The browser's btoa() encodes anything non-ASCII as Latin-1 without complaining; this does not, so accented content and CJK text survive.
• Well-formedness checking. The document goes through the browser's parser and any error is reported, while still encoding what you gave it.
• Standard, URL-safe and MIME output, plus one-click percent-encoding for dropping straight into a query string.
• A live size readout. Bytes in, characters out, and the change as a percentage — which turns negative as soon as compression is on.
• Nothing is transmitted. Signed documents and identity data stay in the tab.

Questions that come up

When do I need the Deflate option?

Only for SAML messages travelling in a URL — the HTTP-Redirect binding. The HTTP-POST binding, where the message rides in a hidden form field, takes plain Base64 with no compression. If you compress for POST or forget to compress for Redirect, the receiving end fails to parse it and rarely tells you why.

My output has + and = in it and the URL is breaking.

Standard Base64 uses characters that mean something else in a URL: + is a legal encoding of a space in a query string, and = separates a parameter from its value. Either switch to URL-safe output or use the percent-encode button. The failure mode when you do neither is nasty, because it depends on the payload — most strings work and the occasional one does not.

Does encoding protect the document?

No. Anyone can reverse it in one paste — Base64 to XML on this site does exactly that. It is transport packaging, nothing more. Confidentiality needs encryption, and integrity needs a signature.

Should I include the XML declaration?

For SAML, most implementations accept a message either way, and many omit it because the encoding is already fixed as UTF-8 by the binding. For a standalone document being stored or emailed, keep it — a consumer reading raw bytes with no other context uses it to work out the encoding.

Why is my compressed output larger for a tiny document?

DEFLATE carries a small amount of fixed overhead, so for a very short fragment there is nothing to gain and the Base64 markup dominates. It pays off from a few hundred bytes upwards, which every real SAML message comfortably exceeds.

Can I encode other formats?

Yes — JSON to Base64, YAML to Base64 and Text to Base64 cover the rest, each with the checks that suit its format.

Related tools

Worth reading

• SAML 2.0 Bindings (OASIS) – §3.4.4.1 spells out DEFLATE-then-Base64-then-URL-encode, in that order
• MDN: CompressionStream – The browser API doing the deflating here, including which formats are available