Skip to content
Start with Identity
Join free
Free tool · SAML 2.0 · client-side

SAML Response Decoder

Paste a SAMLResponse or SAMLRequest from your browser's developer tools or a SAML tracer. The decoder handles base64 (HTTP-POST binding) and URL-encoded, deflated values (HTTP-Redirect binding), shows the fields an SP actually checks, and lists likely misconfigurations. New to the protocol? Start with SAML 2.0 explained.

How it works and what to check

SAML 2.0 messages travel through the user's browser. With the HTTP-POST binding the IdP posts a form field named SAMLResponse that holds base64-encoded XML. With the HTTP-Redirect binding, used mostly for AuthnRequests and logout messages, the XML is compressed with raw DEFLATE, base64-encoded and URL-encoded into a query parameter. The tool reverses those steps, caps the inflated size at 4 MB so a compressed bomb cannot freeze the tab (the bug class behind CVE-2025-25293), and parses the result with the browser's XML parser.

What an SP must check, and where to look

  • Signature and what it covers. Each ds:Signature has a Reference URI that must point at the ID of the element the SP consumes. A Response with several assertions, or a Reference that points elsewhere, is the XML signature wrapping pattern seen in ruby-saml CVE-2024-45409, CVE-2025-25292 and samlify CVE-2025-47949.
  • Algorithms. RSA-SHA1 and SHA-1 digests still show up in older IdP configurations. Move to RSA-SHA256.
  • Issuer and certificate. The Issuer must match the IdP entity ID you configured, and the signing certificate must be the one in your configuration. The tool prints the SHA-256 fingerprint of any embedded certificate so you can compare it; an embedded certificate on its own proves nothing.
  • Audience, Recipient, Destination. Audience should be your SP entity ID; Recipient and Destination should be your ACS URL. Mismatches are the most common cause of "invalid audience" and "invalid destination" errors after a URL change.
  • Time window. NotBefore, NotOnOrAfter and the SubjectConfirmationData NotOnOrAfter are compared with your clock and the skew allowance you set.
  • InResponseTo. Present when the SP started the login. Absent means IdP-initiated SSO, where the SP needs a replay cache because it has no request ID to match.
  • NameID and attributes. Check the format the SP expects. Email-format NameIDs break when people change names; a persistent identifier is safer for account linking.

Why there is no signature verification

Verifying an XML signature means canonicalizing the signed element with exclusive C14N exactly as the signer did, recomputing digests, and checking the signature against a certificate you trust out of band. Browsers ship no XML canonicalization, and differences between parsers and canonicalizers are themselves the root cause of bypasses such as CVE-2025-23369 and CVE-2025-25291. A home-made verifier here would invite exactly the false trust those bugs exploit, so the tool reports presence and structure only. Encrypted assertions are detected but not decrypted, since that needs the SP private key.

Related

Frequently asked questions

How do I decode a SAML response?
A SAMLResponse sent with the HTTP-POST binding is base64-encoded XML, so base64-decoding it gives you the XML. A SAMLRequest sent with the HTTP-Redirect binding is compressed with raw DEFLATE, then base64-encoded, then URL-encoded, so you reverse all three. This tool detects which encoding was used and does the steps for you in the browser.
Does this SAML decoder verify the signature?
No. It shows whether the Response and the Assertion carry signatures, what each signature references and which algorithms they declare, but it does not verify them. Verification needs the IdP signing certificate you already trust and exact exclusive XML canonicalization; a browser tool that guessed at either would give false confidence. Your SP library must verify against the pinned IdP certificate.
Is it safe to paste a production SAML response here?
Decoding happens entirely in your browser with built-in APIs, and the page makes no network request with what you paste. A captured SAMLResponse is still a bearer credential until it expires, and it contains personal data, so prefer test accounts and expired captures.
Why does my SAML assertion show as expired?
Assertions are short-lived: NotOnOrAfter is usually a few minutes after issue. A message captured earlier will show as expired, which is expected. If a fresh assertion is rejected as not yet valid or expired, compare the IdP and SP clocks; the skew field lets you test what allowance your SP needs.
Should the SAML Response or the Assertion be signed?
SAML 2.0 allows either. A signature on the Assertion protects it wherever it travels; a signature on the Response covers the whole message. What matters most is that the SP verifies the signature and then consumes only the element that signature covers, which is what XML signature wrapping attacks get wrong.