SAML Decoder

Paste a SAMLResponse or SAMLRequest and see the decoded, formatted XML instantly. This tool URL-decodes, Base64-decodes, and (for the redirect binding) inflates the DEFLATE-compressed payload automatically — entirely in your browser. Nothing is uploaded.

How to decode a SAML response

A SAMLResponse is a Base64-encoded XML document — and, in the redirect binding, it's DEFLATE-compressed and URL-encoded on top of that. To read it you reverse those layers in order: URL-decode, Base64-decode, and (if needed) inflate the DEFLATE stream. This tool detects which layers are present and applies them automatically. Paste the raw value above and the formatted XML appears instantly, alongside a summary of the key fields. Everything runs locally — you can confirm in DevTools → Network that decoding fires no request.

POST binding vs Redirect binding

SAML sends messages two ways, and they wrap the XML differently. The HTTP-POST binding (used for most SAMLResponse assertions) is simply Base64(XML) — decode the Base64 and you have XML. The HTTP-Redirect binding (common for SAMLRequest, where the message rides in a URL query string) is Base64(DEFLATE(XML)), additionally URL-encoded. If you Base64-decode a redirect value and get binary garbage instead of <samlp:...>, that's the DEFLATE layer — you have to inflate it. This tool auto-detects both.

Note the redirect binding uses raw DEFLATE (RFC 1951, no zlib header), which is why a generic "inflate" that expects a zlib wrapper often fails on SAML. This tool tries deflate-raw first.

Reading the assertion

Once the XML is readable, a handful of fields tell you almost everything you need to debug an SSO handshake:

• Issuer — the entity ID of the identity provider that produced the message. It must match what your service provider is configured to trust.
• NameID — the subject: who the assertion is about, plus its Format (email address, persistent, transient, etc.). This is the identity your app keys off.
• Conditions — the NotBefore / NotOnOrAfter validity window. A tiny window plus clock skew between IdP and SP is a classic "assertion expired" cause. This tool compares the window to your current time and flags valid now, expired, or not yet valid.
• Audience — the intended recipient (your SP's entity ID) inside AudienceRestriction. A mismatch here means the IdP built the assertion for a different application.
• Attributes — the claims (roles, groups, email, department…) the IdP asserts about the user. Missing or misnamed attributes are the usual reason authorization fails after a successful login.

Is this private? Is the signature verified?

Private: yes. The decode runs entirely in your browser with JavaScript — the value is URL-decoded, Base64-decoded, inflated, and parsed locally, and nothing is uploaded. That matters here because SAML assertions are credentials: anyone holding a valid, signed assertion can often impersonate the user, so pasting one into a server-side tool leaks it.

Signature: no. This tool does not verify the XML digital signature. It shows whether a <Signature> / <X509Certificate> is present, but presence is not validity. Decoding is not trusting — never treat a decoded assertion as authenticated. Real signature and condition validation must happen in your SAML library or identity service.

"SAML message not properly Base64 encoded" (AADSTS750056)

This Microsoft Entra ID (Azure AD) error — and its equivalents on other IdPs — almost always means the value was mangled in transit, not that your SAML is wrong. The usual culprits: a + stripped or turned into a space by a proxy or URL handler (Base64's + is a space in application/x-www-form-urlencoded), or 76-character line wrapping that inserted newlines into the string. Fix it by URL-decoding the value (turning spaces back into +) and stripping line breaks before Base64-decoding. This tool does both automatically — it replaces spaces with + before URL-decoding and ignores whitespace when decoding.

Frequently asked questions

How do I decode a SAML response?

Paste the raw SAMLResponse value into the decoder above. It URL-decodes, Base64-decodes, and (for the redirect binding) inflates the DEFLATE payload automatically, then shows the formatted XML plus a summary of Issuer, NameID, Conditions, Audience, and Attributes — all locally in your browser.

Why is my SAMLRequest not valid XML after Base64 decoding?

Because it's the redirect binding, where the message is DEFLATE-compressed before Base64 encoding. Base64-decoding alone leaves you with raw DEFLATE bytes, not XML — you also have to inflate them. This tool detects that and inflates the raw DEFLATE stream for you.

Is it safe to decode a SAML assertion online?

Only if the tool is client-side, like this one — it runs 100% in your browser and uploads nothing. A SAML assertion is a credential, so never paste a production assertion into a server-side tool that sends the value to its backend.

Does this verify the SAML signature?

No — this tool only decodes and formats the message so you can read it. It flags whether a signature is present but does not validate it, the certificate, or the conditions. Decoding is not trusting; verify signatures in your SAML library.

What does AADSTS750056 mean?

It's the Entra ID error "SAML message was not properly Base64 encoded" — usually a stripped + (turned into a space) or bad line wrapping that corrupted the value in transit. URL-decode the value and remove line breaks before decoding; this tool handles both automatically.