SAML Response Decoder

Overview

The SAML response decoder takes a base64 (or base64+DEFLATE) SAML request or response and pretty-prints the underlying XML. Drop in the value from a SAMLResponse form parameter or an &SAMLRequest= query string, and the tool unwraps the wire format and returns indented, syntax-highlighted XML you can actually read.

It is the right tool when an SSO trace shows a wall of base64 and you need to know whether it is a request, a response, an artifact, or a logout — and what the IdP or SP actually put inside. SAML response decoders are a daily companion for identity engineers, security analysts, and anyone debugging a "this assertion is invalid" SSO failure.

How it works

SAML 2.0 wire formats follow the binding rules in OASIS SAMLBindings. HTTP-POST binding base64-encodes raw XML; HTTP-Redirect binding base64-encodes a DEFLATE-compressed XML payload (RFC 1951 raw deflate, no zlib container). The tool tries:

1. Strip whitespace, URL-decode if the input looks URL-encoded.
2. Base64-decode (handling both standard and URL-safe alphabets, with or without padding).
3. If the decoded bytes look like XML (starting with <), use them directly.
4. Otherwise, attempt raw DEFLATE inflation and try again.

The resulting XML is parsed once for validity, then re-serialised with consistent indentation, namespace prefix normalisation, and line breaks between elements. The top-level element tag (samlp:Response, samlp:AuthnRequest, samlp:LogoutRequest) tells you which side of the SSO conversation you are looking at.

Examples

Input:  base64 of HTTP-POST AuthnRequest
Output:
<samlp:AuthnRequest
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_abc123"
    Version="2.0"
    IssueInstant="2026-05-18T14:00:00Z"
    Destination="https://idp.example/sso"
    AssertionConsumerServiceURL="https://sp.example/acs"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
  <saml:Issuer>https://sp.example/metadata</saml:Issuer>
  ...
</samlp:AuthnRequest>

Input:  base64+deflate of HTTP-Redirect Response
Output: pretty-printed <samlp:Response> with nested <saml:Assertion>

Input:  empty / non-base64
Output: Decode error — input is not valid base64

FAQ

HTTP-POST or HTTP-Redirect — which am I looking at?

If the input came from a <form> <input type="hidden">, it is HTTP-POST (base64-only). If it came from a query string (?SAMLRequest=...&RelayState=...), it is HTTP-Redirect (base64 + DEFLATE). The decoder handles both transparently.

Does it validate the schema?

It parses XML for well-formedness but does not validate against the SAML XSDs. Mismatches against the schema surface elsewhere — usually in the IdP or SP's error log.

Why is the XML missing some namespaces in my browser?

Pretty-printing preserves namespaces but can move declarations to the most natural element. The semantics are unchanged; if your downstream tool is strict about namespace placement, copy the raw decoded XML rather than the pretty-printed view.

Can I re-encode the XML back into the wire format?

The reverse direction (compress + base64) is a different tool. This decoder is one-way; encoding is straightforward once you know the binding.

Try SAML Response Decoder