Skip to main content
QUIETLYTIC
Developer

SAML Response Decoder

Decode a SAMLResponse and read its issuer, subject, conditions and attributes.

Local · nothing leaves this browser Waiting for a message
Esc Clear
Show
Message

Paste a SAMLResponse value. Base64 or DEFLATE, both work.

How it works

Paste the value of the SAMLResponse form field and this decodes it, inflates it if it was compressed, and reads out the fields an SSO problem usually turns on: who issued it, where it was addressed, what the status says, who the subject is, and what window it is valid in. Everything happens in your own tab — a SAML assertion is a live credential, and pasting a production one into a server-side decoder hands it to whoever runs that server.

Two bindings, two encodings

An HTTP-POST binding sends the message Base64-encoded and nothing else. An HTTP-Redirect binding raw-DEFLATEs it first so the whole message survives being a query parameter. Rather than asking which you have, this detects: it decodes the Base64, and if the result is not XML it inflates, using the browser’s own DecompressionStream. The binding it found is reported with the result.

It decodes; it does not verify

A SAML signature can only be checked against the identity provider’s certificate, which this page does not have and will not ask you for. It reports that a Signature element is present, because presence is a fact it can establish — validity is not. Those are different things, and treating an unverified assertion as validated is the specific error that makes a decoder dangerous rather than merely limited. The same position the JWT Decoder takes, for the same reason.

Why a DOCTYPE is refused rather than ignored

A document type declaration is where XML external entity attacks live — the construct that turns parsing a document into reading a file off the parser’s host. A SAML message has no legitimate use for one, so a message carrying it is rejected and told so, rather than quietly stripped. If you are looking at one in an incident, that is itself the finding.

Conditions and the clock

The validity window is compared against your machine’s clock, and clock skew between it and the identity provider is a more common cause of a just-expired assertion than genuine lateness. That is why the raw NotBefore and NotOnOrAfter values are shown beside the verdict rather than only the verdict. NotOnOrAfter is exclusive: a time equal to it is already outside.

Example

The sample is a synthetic Response for sp.example.com — fictional throughout, because shipping a captured assertion as sample data would publish the exact thing this tool exists to keep local. It carries a Success status, an email-format NameID, a one-hour conditions window that has long since closed, a signature this page can see and cannot check, and a multi-valued group attribute.

Frequently asked questions

Where do I find the SAMLResponse value?

Open devtools, switch to the network panel, start the sign-in, and find the POST to your service provider’s assertion consumer URL. The SAMLResponse form field holds it. Copy the value only — not the surrounding HTML.

Why do some messages need inflating and others do not?

The binding. HTTP-POST sends the message Base64-encoded and nothing more. HTTP-Redirect raw-DEFLATEs it first so it survives being a query parameter. This page detects which it was handed rather than making you pick, and reports the binding it found.

Is my assertion sent anywhere?

No. Base64 decoding, DEFLATE inflation and XML parsing all happen in your tab, using the browser’s own DecompressionStream. That matters more here than on most tools: a SAML assertion is a live credential, and pasting a production one into a server-side decoder hands it to whoever runs that server.

The conditions window says expired — is that the problem?

Often, and clock skew is the usual cause rather than genuine lateness. The window is compared against your own machine’s clock, which is why the raw NotBefore and NotOnOrAfter values are shown beside the verdict. NotOnOrAfter is exclusive: a time equal to it is already outside.

Why does it say a signature is present but not whether it is valid?

Because presence and validity are different facts, and only one of them can be established without the identity provider’s certificate. Reporting an unverified signature as valid is the specific error that makes a decoder dangerous, so this page reports what it can see and stops.

How is this different from the JWT Decoder?

Same shape of job on a different token format. SAML is XML delivered through a browser redirect or form POST and carries a full assertion with conditions and attribute statements; a JWT is compact JSON usually sent in a header. Both are signed rather than encrypted, so both are readable by anyone holding them.

Related tools

From the intelligence desk