Find out what a SAML message says, and why a sign-in failed
Paste a SAMLResponse or SAMLRequest, the web address or form it came in, a HAR file from your browser, or the XML itself. The decoder finds the message, undoes the Base64 and the compression the redirect binding uses, and explains it in a sentence: who sent it, for which service and user, whether it succeeded and how long it is valid. Status codes, NameID formats, sign-in methods and attributes are explained, the audience and ACS URL are checked against what you expect, and signatures and their certificates are shown.
SAML questions this answers
Read a response from a form post
Input
SAMLResponse=PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxw…
Result
A successful SAML response from idp.example.com for https://app.example.com, signing in avery@example.com. Valid for another 5 minutes.
The value is found in the form body and decoded from Base64. A response that is still valid is flagged, because it may sign the user in until it expires.
Why a sign-in was refused
Input
StatusCode: Requester / RequestDenied
Result
The identity provider refused. Often the user isn’t assigned to this app, or a policy blocked them.
Every SAML status code is explained in plain English, with the identity provider’s own message beside it.
Spot a near miss
Input
Expected audience: https://app.example.com/ Audience in the assertion: https://app.example.com
Result
They differ only by a trailing slash, and SAML compares them exactly.
Add the entity IDs and ACS URL your service expects in the settings. Each is compared exactly, and near misses are named.
How to read and debug a SAML message
- Paste the SAMLResponse or SAMLRequest value, or whatever holds it: the address from the address bar, the form body or HAR file from the browser’s developer tools, or the XML.
- Read the answer at the top, then the status, timing, user, attributes and signatures. The XML tab holds the decoded message, formatted.
- In the settings, add the service provider’s entity ID, its ACS URL and the identity provider’s entity ID to compare them exactly, and a clock tolerance or a time to check at.
- Copy summary describes the result for a ticket without the user, addresses or attribute values.
SAML decoder questions
Is the SAML message sent anywhere?
No. It is decoded in your browser and never uploaded, stored or put in the page address. A response that hasn’t expired may still sign the user in, so treat it like a password.
Does this check the signature?
No. It shows where the message is signed, with which algorithm and certificate, but checking needs the identity provider’s trusted certificate, which your service holds. A readable message isn’t proof it’s genuine.
Can it read encrypted assertions?
No. Only the service provider’s private key can decrypt them, and this page never asks for one. It shows that the assertion is encrypted and how.
Which messages can it read?
SAML 2.0 responses, sign-in requests, sign-out requests and responses, assertions and metadata, sent with HTTP-POST or HTTP-Redirect, and SAML assertions inside WS-Federation responses. It recognizes Microsoft Entra ID, AD FS, Okta, Google, Auth0, Keycloak and other identity providers by their issuer.
What does it warn about?
Failed statuses, expired or not-yet-valid messages, a missing audience, a destination that doesn’t match the recipient, unsigned messages, SHA-1 signatures, expiring certificates, and the patterns behind signature-wrapping and comment-injection attacks.
Reading is not verifying
This tool reads SAML; it doesn’t check signatures, decrypt assertions or contact any identity provider. Your service’s own rules, such as the clock difference it allows or the attributes it needs, can still refuse a message that looks right here.