SAML Assertion Decoder

Decode, inspect, and debug SAML responses and assertions for enterprise SSO integrations

Paste the Base64 value from the SAMLResponse POST parameter
Paste the raw XML of a SAML Response or Assertion
Paste a URL-encoded (and possibly Base64-encoded) SAML value
Response Overview
Assertion Details
Subject
Conditions
Authentication Statement
Attributes
NameValue(s)
Signature
Formatted XML

Understanding SAML

How Security Assertion Markup Language powers enterprise single sign-on

What is SAML?

SAML 2.0 is an XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). It's the backbone of enterprise SSO.

The SAML Flow

The user authenticates at the IdP, which issues a signed SAML Response containing assertions about the user's identity and attributes. The SP validates the signature and grants access.

Assertions

A SAML Assertion contains the Subject (who), Conditions (when it's valid), Authentication Statements (how they logged in), and Attribute Statements (user data like email, roles, and groups).

Anatomy of a SAML response

Encoding layers

A SAML response arriving at your ACS endpoint is typically base64-encoded XML. If it came via HTTP-Redirect binding rather than HTTP-POST, it is also DEFLATE-compressed and URL-encoded on top of that — three layers to unwrap before you see markup.

This is why a response that looks like garbage often just needs another decoding pass. Redirect binding is normally used for the request rather than the response, since responses tend to exceed practical URL length limits.

The parts that matter

The Assertion carries the identity claims. Subject holds the NameID — the user identifier, whose Format determines whether it's an email, a persistent opaque ID, or transient. AttributeStatement carries everything else the IdP chose to send: groups, roles, display name.

Conditions defines the validity window with NotBefore and NotOnOrAfter, plus AudienceRestriction naming who the assertion is for. That audience must match your entity ID; if it doesn't, the assertion was minted for a different service provider.

Signature placement

SAML permits signing the response, the assertion, or both, and the difference matters. If only the response is signed, an attacker who can wrap the XML may be able to substitute an assertion — the XML Signature Wrapping class of attack.

Verify what is actually signed and confirm the signed element is the one you're reading claims from. This is a well-known source of authentication bypasses in SAML implementations, and it's why using a maintained library rather than hand-parsing XML matters here more than almost anywhere else.

Frequently asked questions

No. Decoding runs entirely in your browser. Assertions frequently contain personal data such as email addresses and group memberships, so this is worth confirming for any tool you paste one into.

Check the Conditions window first — clock skew between the IdP and your service provider is the most common cause, and a minute of drift is enough. Then check AudienceRestriction matches your entity ID exactly, and that the certificate you're verifying with is the IdP's current signing certificate.

The response wraps the assertion. Signing only the response leaves room for XML Signature Wrapping attacks, where an attacker restructures the document so your parser reads an unsigned assertion while the signature check passes on a different element. Signing the assertion, and verifying that the element you read claims from is the signed one, is the safer configuration.

Persistent gives a stable opaque identifier per user per service provider, which is generally the right choice — it survives email changes and doesn't leak personal data. EmailAddress is convenient but breaks when a user's address changes. Transient produces a new value each session and is only suitable for anonymous federation.

OIDC for anything new — it is JSON over HTTPS, far simpler to implement correctly, and has a smaller attack surface. SAML remains necessary because a large number of enterprise identity providers support it and some customers require it. Most platforms end up supporting both.

Next steps

Related tools

In the docs

All developer tools

Enterprise SSO without the SAML archaeology

Okta, Azure AD, Google Workspace, ADFS, PingFederate, JumpCloud — configured from the dashboard instead of hand-parsing assertions.

Start free Set up a SAML connection

Free, unlimited users. No credit card required.