SAML Decoder

The tool supports Base64-encoded SAML Response and Assertion XML, commonly found in SAML redirects and POST bindings. It also auto-detects and inflates deflate-compressed SAML requests.

Yes. All processing happens entirely in your browser. Your SAML tokens are never sent to any server. No data leaves your device.

SAML requests sent via HTTP redirect are often deflate-compressed before Base64 encoding to reduce URL length. This tool automatically detects and decompresses such data.

A request is a samlp:AuthnRequest that the service provider sends to ask the identity provider to authenticate a user; a response is the samlp:Response coming back, carrying the saml:Assertion with the authentication statement and attributes. Both travel URL-encoded (Redirect binding) or inside an HTML form POST (POST binding). This tool decodes either direction.

An opaque string the SP attaches to the request that the IdP must return unchanged with the response - typically the URL to redirect to after login. The SAML bindings spec recommends keeping it under 80 bytes, and it carries no meaning to the IdP. When SSO lands on the wrong page, a dropped or corrupted RelayState is a prime suspect.

In the HTTP-Redirect binding the XML is raw-Deflate compressed, then Base64, then URL-encoded - the three steps the spec mandates. Give this tool the URL-encoded value: if it expands into markup starting with <, it was compressed; if it already starts with <?xml or <saml, it wasn't. POST-binding messages are Base64 without Deflate.

Clock skew - signature validation fails when SP and IdP clocks differ by more than the allowed drift; audience mismatch - the audienceRestriction in the assertion doesn't contain the SP's entity ID; and expired responses (NotOnOrAfter). Also common: a missing RelayState and unsigned assertions where the SP requires them. The decoded fields this tool shows let you check each of these directly.

Yes - decoding is not verification. The assertion's XML is readable by anyone; the signature inside covers integrity, not confidentiality. What you cannot do without the IdP's public certificate is prove the assertion is authentic and unmodified. Treat any decoded content carefully: assertions often carry email addresses, groups, and entitlements.