SAML Decoder

SAML 2.0 is the protocol behind many corporate single sign-on logins. A browser carries XML messages between your application, the service provider, and the company’s identity provider. When a login fails with “invalid audience”, “assertion expired” or a vague error page, the answer is almost always inside one of those messages, but they travel as dense, encoded text. This decoder undoes the encoding and points out the fields you actually need.

How messages are encoded

SAML defines bindings, ways of carrying a message. With the HTTP-Redirect binding the message is part of the URL, so it has to stay short: the XML is compressed with raw DEFLATE, Base64-encoded, then URL-encoded into a SAMLRequest or SAMLResponse parameter. With the HTTP-POST binding the browser submits an HTML form with a hidden field, and the XML is only Base64-encoded. The page works out which applies: paste the value, the whole URL, the form field or even the finished XML.

A worked example

Press Sample. The page decodes a sample AuthnRequest. Under “What it says” it lists the document type AuthnRequest, the ID _a75adf55-01d7-40cc-929f-dbd8372ebdfc, issue time 2026-11-02T10:15:00Z, destination https://idp.example.test/sso, assertion consumer service URL https://sp.example.test/acs and issuer https://sp.example.test/metadata, and notes that there are no signatures. Below, the pretty-printed XML shows the same facts plus the request’s NameID policy, format e-mail address with AllowCreate true, and the requested response binding HTTP-POST.

Reading a response

A SAMLResponse adds the parts you debug: the status code, which says Success or an error; the assertion with its conditions, NotBefore and NotOnOrAfter, which define the validity window; the audience restriction; the subject’s name ID and its confirmation data; and the attribute statement listing values such as e-mail and groups. The summary shows these, and the XML is below for anything else. Clock difference between the two systems is a classic cause of “assertion not yet valid” or “expired” errors, so compare the times in the message with the clock of the receiving server.

Frequent causes of failure

A destination or assertion consumer URL that differs by a trailing slash or by http versus https. An audience that does not equal the entity ID configured in the service provider. A name ID format the application does not expect. A certificate that rotated, so the signature no longer verifies. Missing attributes because the identity provider does not release them to this application. Each of these is visible in the decoded message.

Limits

Decoding is not validation. The page does not verify XML signatures, does not decrypt encrypted assertions, and cannot tell whether a message is genuine or replayed. A response may contain personal data such as e-mail addresses. It is decoded in your browser and not uploaded, but avoid pasting production responses into any site you do not control, and prefer test accounts.

A debugging routine

Work through a failed login in the same order every time. First decode the AuthnRequest your application sent and confirm the issuer, the assertion consumer service URL and the requested name ID format against the identity provider’s configuration. Then decode the response and read the status before anything else, since a status other than Success usually carries a message. Next compare the audience with your entity ID, the destination with your endpoint, and the validity window with the current time. Last, check the attributes your application expects. Writing down the decoded values for a working login gives you a reference to compare when a later one breaks.

Related tools

• JWT Decoder does the same job for OpenID Connect tokens.
• XML Formatter tidies any XML you extract.
• Base64 Encoder converts the encoded layer by hand.
• SSL Certificate Decoder reads the signing certificate in a message.