About the SAML Response Decoder
A SAML Response is the XML document an identity provider sends to a service provider to assert who a user is. It arrives Base64-encoded in a form POST, or Base64 plus raw DEFLATE in a redirect URL, which makes it unreadable at exactly the moment you need to read it — when single sign-on has stopped working. This tool decodes all three forms, tells you which one it matched, and pulls out the fields that actually explain the failure.
Decoding happens entirely in your browser. That matters more here than for most tools: a SAML Response carries a real person's name, email address, group memberships, and session identifier. Pasting production identity data into a third-party server is the thing most engineers are rightly unwilling to do, so nothing here is uploaded, logged, or transmitted.
The tool reports whether the Response, the Assertion, or both carry an XML signature, and which algorithms were used — but it does not verify that a signature is valid. Correct verification requires XML canonicalisation and the identity provider's trusted certificate, and a decoder that quietly gets canonicalisation wrong is more dangerous than one that never claims to check.
Frequently asked questions
Where do I find the SAML Response to paste in?
Open your browser's developer tools, go to the Network tab, and reproduce the login. Find the POST request to your service provider's ACS (Assertion Consumer Service) URL and copy the entire value of the SAMLResponse form field. For a redirect binding, copy the SAMLResponse or SAMLRequest query-string parameter from the URL instead.
Does this tool verify the SAML signature?
No, and that is deliberate. It reports that a signature exists, where it sits, and which signature and digest algorithms are named. Actually verifying an XML signature requires XML canonicalisation (C14N) plus the IdP's trusted certificate, and a subtly incorrect C14N implementation produces confidently wrong verdicts — worse than offering no verdict at all.
Why does my SAML Response say Success but login still fails?
Usually an audience or timing problem. Check that the Audience matches your service provider's entity ID exactly, and that the current time falls inside the NotBefore and NotOnOrAfter window — clock skew of even a minute between IdP and SP is a common cause. After that, check whether the NameID format is the one your SP expects.
Can it decrypt an encrypted assertion?
No. Decryption requires the service provider's private key, which this tool never asks for and could not safely handle in a browser. When an EncryptedAssertion is present the tool says so clearly and still shows the readable envelope fields — issuer, destination, and status — which are often enough to diagnose the problem.
Why does my SAML XML use saml2: in some places and saml: in others?
Those are just namespace prefixes and they carry no meaning of their own — Okta emits saml2:, ADFS tends to emit saml:, and some providers use no prefix at all. What matters is the namespace URI each prefix is bound to. This decoder matches on namespace URIs rather than prefixes, so it reads documents from any provider identically.