Read SAML messages with this SAML decoder
SAML single sign-on sends XML messages between your application (the service provider) and the identity provider, but you never see that XML directly. It travels as Base64 in a form field or compressed inside a URL. This saml decoder reverses those encodings and shows the message as formatted XML, so you can see why a login fails: a wrong audience, an expired assertion, a missing attribute or an unexpected NameID format.
What is a SAML message?
In SAML 2.0 web SSO, the service provider sends an AuthnRequest to the identity provider, which authenticates the user and returns a Response containing an Assertion. The assertion names the user (NameID), limits where and when it is valid (Conditions, Audience), and carries attributes such as email or group membership. Usually the response or the assertion is signed with XML Signature.
Encodings the decoder handles
- HTTP-POST binding: the
SAMLResponseform field is plain Base64 of the XML. This is what you usually copy from the network tab. - HTTP-Redirect binding: the
SAMLRequest(or response) in the URL is raw DEFLATE compressed, then Base64 encoded, then URL-encoded. All three layers are undone. - Full URLs and form bodies: paste a whole URL or a
SAMLResponse=…&RelayState=…string, and the SAML parameter is extracted for you. - Plain XML: pasted XML is simply formatted and summarized.
Spaces inside the Base64 are treated as + characters, which fixes a common copy-and-paste problem when a + was turned into a space by form decoding.
Example
Show summary on the sample response produces this (a few lines left out):
Message: Response (ID _8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6)
Issued: 2026-09-01T09:22:05Z
Destination: https://sp.example.com/saml/acs
Issuer: https://idp.example.org/metadata
Status: Success
NameID: jane.doe@example.com [emailAddress]
Valid: 2026-09-01T09:21:35Z → 2026-09-01T09:27:05Z
Audience: https://sp.example.com/metadata
Signatures: none
Attributes:
email: jane.doe@example.com
groups: engineering, admins
Decode to XML shows the same message as indented XML, starting with <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" …>. The status line tells you which layers were removed, for example "Decoded via Base64 + DEFLATE (HTTP-Redirect binding)". When a response carries more than one assertion, the summary prints a separate block for each ("Assertion 1 of 2") with its own NameID, validity window, audience and attributes.
Debugging common SSO failures
- Audience mismatch: the
Audiencemust equal your service provider entity ID exactly, including the trailing slash and the scheme. - Assertion expired: compare the Valid window with your server clock. Assertions are often valid for only a few minutes, so clock drift of a minute or two can cause failures.
- Wrong Destination or ACS URL: the value must match the URL that received the POST. Proxies that change http to https are a frequent cause.
- Status is not Success: codes such as Requester or AuthnFailed come from the identity provider. Check its logs rather than your application. The summary's Status line shows the top-level code followed by any second-level code (for example
Responder › AuthnFailed), and aStatusMessagefrom the provider is printed on its own line. - Attributes missing: the identity provider has not released them to your application. Look at the attribute names, which are often URIs rather than friendly names.
What the decoder does not do
The summary counts Signature elements and names the element each one signs, but it does not verify them cryptographically. If the message contains an EncryptedAssertion, the summary says so. Decrypting it requires the service provider's private key, which this tool does not ask for. To inspect the signing certificate, copy the Base64 text inside ds:X509Certificate into the certificate decoder, which accepts it without PEM headers.
For other XML work, the XML formatter can re-indent any document. If you only need to undo one layer by hand, use Base64 decode or URL decode.
Privacy
SAML responses contain personal data and are, until they expire, usable login tokens. This decoder runs entirely in your browser: Base64, URL decoding, DEFLATE and XML parsing all happen locally, and nothing is uploaded. Even so, avoid sharing decoded production assertions in tickets or chat.