SAML Decoder & Response Validator
Decode a SAMLResponse, SAMLRequest, redirect URL or raw XML, then see what might get it rejected: the status, time windows, audience, destination, signatures and signing certificate.
Decoded locally in your browser. Nothing is uploaded.
Accepted: a base64 SAMLResponse or SAMLRequest, a full redirect URL, a query string or form body, DevTools payload lines, or raw XML.
About SAML Decoder & Response Validator
This SAML decoder takes what you captured from a failed single sign-on (a SAMLResponse from the network tab, a SAMLRequest redirect URL, a form body, or raw XML) and decodes it in your browser. It works as a SAML response decoder and a SAML request decoder from the same box, and it lists each decoding step it took, so you can see how the value was encoded. The two bindings encode differently. HTTP-POST sends the XML as plain base64. HTTP-Redirect compresses it with raw DEFLATE first, then base64-encodes and URL-encodes it, which is why a plain base64 decode of a SAMLRequest returns binary instead of XML.
Beyond decoding, the verdict panel works as a SAML response validator. It covers the conditions a service provider checks: the status code, the NotBefore and NotOnOrAfter windows with a clock skew you choose, the Audience, Destination, Recipient and InResponseTo values, and the Issuer. Type the values your SP expects and each row turns into a pass or a fail, with a hint when two values differ only by a trailing slash, letter case, or http and https. The headline names the first check that might make the receiver reject the message.
The signature map shows which element each XML signature covers and whether its Reference points at the element it sits in, and it flags the structures signature-wrapping attacks depend on. The embedded signing certificate is decoded with its fingerprints and expiry date, then compared with the certificate you paste.
The XML signature of a POST message is not verified. A certificate match shows which certificate the message names, not that it was signed with it. Encrypted assertions are detected but not decrypted. A Redirect signature is verified with a certificate you paste, so the result is only as good as the source of that certificate. Everything is decoded locally, and nothing is uploaded.
How to decode a SAML response
- Capture the message. In DevTools open the Network tab with Preserve log on, sign in, and copy the SAMLResponse form value from the POST to your ACS URL, or copy the whole redirect URL to the IdP. A SAML-tracer capture works too.
- Paste it as is. The Detected line lists how it was decoded (URL decoding, base64, and for the Redirect binding a raw DEFLATE inflate). If form decoding turned + signs into spaces, the decoder puts them back and says so.
- Read the verdict. Open Check against and type your SP entity ID, ACS URL, request ID and IdP entity ID to turn the Audience, Destination, Recipient, InResponseTo and Issuer rows into a pass or a fail.
- Set the clock skew to what your SP allows. Each time window (Conditions NotBefore, NotOnOrAfter, the bearer NotOnOrAfter) is its own row, and an expired one says how long ago it expired.
- Open Signatures to see whether the Response, the Assertion, or both are signed, and what each signature references.
- Paste the IdP signing certificate or its fingerprint from IdP metadata to compare it with the embedded one. This shows which certificate the message names; it is not a signature check. For a redirect URL, the same certificate verifies the query-string signature.
- Copy the original or the formatted XML, copy the attributes as JSON, or open the XML in the Selector Tester to query it with XPath.
Common Use Cases
"Audience invalid" after a new integration
The SP rejects every login with an audience error. Paste the response and the page acts as a SAML assertion decoder: the Audience sits next to the SP entity ID you typed, and when the two differ only by a trailing slash or letter case (the usual cause), the near-miss hint names the difference.
Login broke after the IdP rotated its certificate
The embedded certificate no longer matches the fingerprint in the SP configuration. The certificate row says so and names the subject and SHA-256 fingerprint of the certificate the message now carries, so you know what to update in the SP.
A Redirect-binding AuthnRequest the IdP rejects
Paste the whole redirect URL and the SP certificate. The signature is checked over the raw query string, the way the binding defines it. When it fails, the page names a likely cause, such as RelayState left out of the signed string or values that were re-encoded.
Reviewing signature placement
For a security review, the Signatures tab shows which element is signed, whether the Reference points at it, and the red flags reviewers look for: a second assertion, a duplicate ID, a comment inside NameID, or a signature in an unexpected place.
Frequently Asked Questions
How do I decode a SAML response?
1. If it came from a URL or a form body, URL-decode it. 2. Base64-decode it. 3. Only for the HTTP-Redirect binding, inflate the result with raw DEFLATE (RFC 1951). A SAMLResponse posted to your ACS URL uses the HTTP-POST binding, so steps 1 and 2 give you the XML directly. A SAMLRequest in a redirect URL uses the HTTP-Redirect binding, so after base64 you still have compressed bytes until you inflate them. This page detects which case you pasted and runs the right steps.
Why is my SAMLRequest not valid XML after base64 decoding?
The HTTP-Redirect binding compresses the message with raw DEFLATE (RFC 1951) before the base64 step, so a base64 decode alone returns binary. Inflate it to get the XML. Some libraries wrap the data in a zlib header (RFC 1950), which the binding does not allow; this page still inflates it and flags it. A value copied out of a form body can also have its + signs turned into spaces, which breaks base64; the decoder turns them back and says how many it repaired.
Why does a SAML response decode fine but still get rejected?
Decoding only shows the content. The SP then checks the status code, the NotBefore and NotOnOrAfter windows against its clock with some skew (common defaults are 1 to 5 minutes, and Shibboleth and OpenSAML default to 3 minutes), the Audience against its entity ID, the Recipient and Destination against its ACS URL, InResponseTo against the request it sent, and the signature against the IdP signing certificate it has configured. The verdict panel gives each of these its own row, except the POST signature itself: it shows what the signature covers but does not verify it.
What does urn:oasis:names:tc:SAML:2.0:status:Responder mean?
The top-level status code says whose side the problem is on: Requester means the request was at fault, Responder means the responder could not or would not answer it. The second-level code carries the actual reason, for example RequestDenied (often a user not assigned to the application), AuthnFailed (the sign-in itself failed), InvalidNameIDPolicy (a NameID format the IdP will not release) or NoAuthnContext (the requested authentication method does not match how the user signed in). The SAML status codes reference lists all 23 codes with what to check for each.
Does this check the SAML signature?
For a POST message, no. The page shows where the signature is, what it references and which algorithms it uses, and it compares the embedded certificate with yours. A match only shows which certificate the message names, because anyone can embed a public certificate. For a Redirect URL, yes: the query-string signature is verified with the certificate you paste. Decoding alone never proves a message came from who it claims.
Is it safe to paste a SAML assertion into an online decoder?
Treat it with care: an assertion contains personal data, and it is a bearer credential until it expires. This page decodes it locally and makes no network requests with it, which you can confirm in the Network tab of DevTools. The share link asks for a second click before it copies anything. Never paste an SP private key into any website, including this one.