SAML Response Decoder

Decode a base64 and DEFLATE-encoded SAML response locally and read the assertion - subject, conditions, audience, timestamps - with XML parsing hardened against entity attacks.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

SAML response, assertion or request Base64, base64url, URL-encoded and DEFLATE-compressed forms are all detected. Decoded locally.

A SAML response is a live credential

While it is inside its validity window, a SAML response is enough to sign in as the person it names. That is worth stating plainly before anything else, because these get pasted into online decoders routinely during troubleshooting - and a decoder that posts to a server has just been handed a working login for whatever the assertion grants.

Everything here happens in your browser: the base64, the DEFLATE, the XML parsing and the analysis.

The XML is the dangerous part

Not the SAML - the XML. XML parsers have a long history of being talked into things by the documents they parse, and both classic attacks come from DTD processing. XXE uses an external entity to make the parser read a local file or fetch a URL. The billion laughs nests entity definitions so a few hundred bytes expand into gigabytes of memory.

Three layers apply here, in order of what actually does the work. The browser's DOMParser in XML mode does not resolve external entities at all - that is a platform guarantee rather than a setting. On top of that, this page refuses any document containing a DOCTYPE or an ENTITY declaration before parsing begins, because a SAML assertion has no legitimate reason to carry one and refusing removes the whole class. Finally there are caps on size, nesting depth and element count, so a merely absurd document fails fast instead of hanging the tab.

What it looks for

Nothing signed at all - a claim about identity with nothing establishing who made it. Anyone who can reach the endpoint can post one.
The response signed but the assertion not. This is the shape signature-wrapping attacks exploit: an attacker restructures the XML so their own unsigned assertion is the one the service provider reads, while the signature still validates against the original element.
SHA-1 signature and digest algorithms, still common in SAML deployments and unsafe against collisions since 2017.
Missing audience restriction, which is what stops an assertion issued for one service provider being replayed at another that trusts the same identity provider.
Validity windows measured in hours. SAML assertions are meant to be consumed within seconds; a long window is a replay window.
Missing InResponseTo or Destination, and bearer confirmation with no Recipient - each removes a binding between the assertion and the request or endpoint it was meant for.
Sensitive attributes. The assertion passes through the browser, so anything in it is visible to the user and to every log that records POST bodies.

It does not verify signatures, and says so

Checking an XML signature properly requires the identity provider's certificate and a correct implementation of exclusive canonicalisation - the algorithm that decides exactly which bytes the signature covers. Getting canonicalisation subtly wrong produces confident false passes, which is worse than not checking at all.

So this page reports where signatures are and what algorithms they use, and marks verification as Unknown. Your SAML library does the actual check - and the thing to confirm about it is that it verifies the signature on the element it consumes, not merely that some valid signature exists somewhere in the document.

Frequently asked questions

Where do I get the response to paste?

Your browser's developer tools, on the POST to the assertion consumer URL - the SAMLResponse form field. A SAML tracer extension shows the same thing more conveniently.

It says the assertion is encrypted and stops there.

An EncryptedAssertion needs the service provider's private key to open, which this page will not ask for. Encryption is a good thing here - it just means only the envelope is readable.

My document was rejected for having a DOCTYPE.

Deliberately. DTD processing is the root of both XXE and entity-expansion attacks, and a SAML assertion never needs one. If a real identity provider is emitting a DOCTYPE, that is worth asking them about.

Why flag a signed response with an unsigned assertion?

Because assertions can be moved. If the assertion carries no signature of its own, an attacker with any validly signed response may be able to restructure the XML so a different assertion is consumed while the original signature still checks out.

Is anything uploaded?

No. Decoding, decompression, parsing and analysis all happen in your browser.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.