SAML Request & Response Decoder
Base64 + raw-deflate, pretty-printed XML — all client-side
Base64 SAML payload (SAMLRequest / SAMLResponse)
Need this on-premise or behind your firewall?
We ship a self-hosted enterprise edition of our identity tools (SAML, OIDC, JWT) — air-gapped, auditable, no data leaves your network. Contact us for details.
About the SAML Decoder
When a SAML flow breaks, the evidence is hidden inside a giant base64 blob on the URL or in an HTML form field. HTTP-Redirect bindings deflate-compress the XML before base64-encoding it; POST bindings base64-encode it directly. Either way, what you get in browser dev tools is unreadable - and pasting production SAML assertions into a random website is a real security risk, since assertions can contain names, emails, and group memberships that act as access tokens.
This decoder runs entirely in your browser using the native DecompressionStream API: raw-deflate decompression plus base64 decoding, then pretty-printed XML showing the AuthnRequest, Subject, conditions, and every attribute statement. Nothing is uploaded, and it also encodes XML back into Redirect-binding format for testing your own SP.
How to use
- Copy the SAMLRequest or SAMLResponse parameter value from the URL or form.
- Paste it in and click Decode - deflate and base64 are handled automatically.
- Inspect the pretty-printed XML: issuer, NameID, attributes, and conditions.
- Switch to Encode to turn SAML XML back into a Redirect-binding payload.
Frequently Asked Questions
What is the difference between SAML Redirect and POST binding? ▾
The Redirect binding packs the XML message into the URL: raw-deflate compression followed by Base64, then URL-encoding. The POST binding puts only Base64 (no compression) into an HTML form field. This decoder auto-detects both - if deflate decompression fails it retries as plain Base64.
Is it safe to paste production SAML assertions here? ▾
Yes. Decoding happens entirely in your browser - assertions are never uploaded to any server. That said, SAML assertions are bearer credentials, so avoid pasting them into tools that cannot prove client-side processing.
Why does my decoded SAML show as broken XML? ▾
The message was likely truncated by URL length limits or copy-paste. Grab the full parameter (SAMLRequest or SAMLResponse) from your browser devtools network tab rather than the visible URL bar.
How do I pretty print a SAML response? ▾
Base64-decode the SAMLResponse parameter, inflate it if it was raw-deflate compressed (most AuthnRequests are), and run the resulting XML through an indenter. This tool does all three steps: paste the value from your browser URL bar, SAML tracer, or IdP export, and you get namespace-preserved, pretty-printed XML you can actually read — attribute statements, conditions, signatures and all.
Why is my SAML XML all on one line? ▾
SAML messages are generated programmatically and transmitted without insignificant whitespace, so the XML arrives as a single line. Pretty printing only adds indentation between elements — it changes nothing semantically, and the signature (if present) still validates because signed XML canonicalization ignores this whitespace.
How do I decode a SAML response from a browser? ▾
Copy the SAMLResponse form field (base64) from your browser's developer tools during login, paste it here, and the decoded XML appears instantly — attributes, conditions, NameID, and signature elements.
Is decoding a SAML response here safe? ▾
Yes — decoding is local. SAML assertions carry identity data and sometimes sensitive attributes, so keeping them out of server-side decoders is the point of a client-side tool.
Why is my SAML response not valid base64? ▾
Browsers URL-encode the POST payload. The toolkit handles the deflate (compressed) variant too — if raw base64 decode fails, it retries with inflation, which most IdPs use.