In one sentence
This tool reverses SAML's transport encodings (base64 for the HTTP-POST binding; DEFLATE, base64 and URL-encoding for the HTTP-Redirect binding) using the browser's DecompressionStream, pretty-prints the XML, and lists the issuer, subject, time conditions, audience, attributes and signature locations so you can compare them with your configuration.
How do I use the SAML Decoder?
Paste the value, click Decode, and read the key fields table first.
- Paste a SAMLResponse (POST binding), a SAMLRequest or full redirect URL (Redirect binding), or XML.
- The status line shows which binding was detected, the parameter name and any RelayState.
- Warnings flag missing signatures, more than one assertion and error status codes.
- The key fields table lists Issuer, NameID, Recipient, Conditions, Audience, AuthnStatement details and signed elements.
- Attributes appear in their own table; the full XML is pretty-printed below.
Try the two sample buttons: a Response for the POST binding and an AuthnRequest encoded for the Redirect binding.
How do the SAML bindings encode messages?
POST binding: base64 of the XML in a form field. Redirect binding: raw DEFLATE, then base64, then URL-encoding in the query string.
| Binding | Encoding | Typical message |
|---|---|---|
| HTTP-POST | Base64 (often with line breaks) | Response from IdP to SP |
| HTTP-Redirect | DEFLATE (no zlib header) + base64 + URL-encode | AuthnRequest, LogoutRequest |
| HTTP-Artifact | Short reference, resolved over SOAP | Less common |
The decoder tries base64 first, and if the result is not XML it inflates with deflate-raw, then with zlib and gzip wrappers for non-conforming implementations.
What should I check in a Response?
Issuer, signature, audience, recipient, destination, time window, InResponseTo and the attributes.
Compare each value with your SP configuration and IdP metadata. Common mismatches: an Audience that differs from your entity ID by a trailing slash, a Recipient with http instead of https, and attribute names in a different format than the application expects. The federation guide explains each check.
Is my assertion uploaded?
No. Decoding, inflating and parsing happen in your browser; nothing is sent anywhere.
Assertions contain personal data and, while valid, can grant access. Prefer test accounts and expired captures.
Questions
Where do I find the SAMLResponse?
Open your browser's developer tools, go to the Network panel, preserve the log, sign in, and find the POST to the service provider's Assertion Consumer Service URL. The SAMLResponse is a form field in that request. For Redirect-binding requests, copy the whole URL with SAMLRequest in the query string.
Does the decoder verify the XML signature?
No. It shows which elements carry a signature, but verifying XML signatures correctly requires the IdP's certificate, canonicalization and protection against signature wrapping, which belongs in a maintained SAML library.
Can it read encrypted assertions?
It detects an EncryptedAssertion and decodes the outer Response. Reading the assertion needs the service provider's private key, which should never be pasted into a web page.
Why do the time checks show 'in the past'?
Assertions are valid for a short window, usually a few minutes. A captured response will normally show NotOnOrAfter in the past by the time you decode it. That is expected; the check matters when you are debugging a live clock-skew problem.
Related reading
- What is identity federation?
- AD FS Claim Rules for LDAP Attribute Stores, Line by Line
- Using an LDAP Attribute Store in AD FS
- SP-Initiated SSO on .NET: From WIF to Modern Libraries
- Microsoft 365 and SAML 2.0: Federating Entra ID With Your IdP
- Extending Your IAM to Cloud Apps: SSO, Provisioning, Reviews
- Federation and Entitlement Management: How They Fit Together