Paste a SAMLResponse, SAMLRequest, a redirect URL or a POST body. The decoder works out the encoding (URL-encoded, base64, DEFLATE), shows the formatted XML and pulls out the user, attributes, audience, signatures and every validity time, checked against your clock. Nothing leaves your browser.
Last updated:
Advertisement
Advertisement
How to use the SAML Decoder
Copy the SAML message from your browser's developer tools (Network tab, the POST to the ACS URL or the redirect to the IdP) or from a SAML tracer extension.
Paste it into the box: just the value, the whole URL, or the form body all work.
Read the summary to see who issued it, which user it is for, the status and the attributes.
Check the validity times; set the clock skew your service provider allows if timing errors are the problem.
Copy the XML or switch to Encode to turn edited XML back into a SAMLRequest or SAMLResponse for testing.
Hidden form field SAMLResponse posted to the ACS URL
HTTP-Artifact
Artifact, then ArtifactResolve / ArtifactResponse
Short artifact reference; the XML is fetched over a back channel
SAMLart parameter
A decoded POST message starts with <samlp:Response or <saml2p:Response; base64 of XML almost always begins with PH (the encoding of <). Deflated redirect messages usually begin with fZ, nZ, jZ or similar.
ACS URL configured differently at the IdP and SP, or a proxy changes the host
"InResponseTo mismatch"
InResponseTo
IdP-initiated login sent to an SP expecting SP-initiated, or the SP lost the request ID (session cookie dropped)
"Signature invalid"
Signature, certificate fingerprint
The IdP rotated its signing certificate; the SP expects the assertion signed but only the response is (or vice versa)
User not found or wrong user
NameID and format, attributes
Wrong NameID format (persistent vs email), attribute names not mapped
Common SAML status codes
urn:oasis:names:tc:SAML:2.0:status:Success: the request succeeded.
…:status:Requester: the request was wrong; look at the second-level code.
…:status:Responder: the identity provider had a problem.
…:status:AuthnFailed: the user could not be authenticated.
…:status:InvalidNameIDPolicy: the requested NameID format is not available.
…:status:NoPassive: IsPassive was requested but the user must interact to log in.
…:status:RequestDenied: the IdP refuses to answer, often because the user is not assigned to the app.
Frequently asked questions
How is a SAMLResponse encoded?
With the HTTP-POST binding the XML is base64-encoded and sent as the SAMLResponse form field, so it often appears URL-encoded in the request body (%2B for +, %3D for =). With the HTTP-Redirect binding, used mostly for AuthnRequests and logout messages, the XML is first compressed with raw DEFLATE, then base64-encoded and URL-encoded into the query string.
Why does base64 decoding a SAMLRequest give unreadable characters?
Because Redirect-binding messages are compressed with DEFLATE before base64 encoding. The decoded bytes must be inflated (raw DEFLATE, RFC 1951) to get the XML. This tool detects that and inflates automatically.
Is it safe to paste a real SAML response here?
The decoding runs entirely in your browser and nothing is sent to a server. Still treat SAML responses like passwords: a bearer assertion that has not expired can be replayed to log in as that user. Prefer test accounts or expired messages when sharing with others.
Does this tool verify the XML signature?
No. It shows what is signed (the Response, the Assertion or both), which algorithms are used and the certificate fingerprint, so you can compare it with the certificate in your IdP metadata. Real signature validation must be done by your service provider's SAML library with the trusted certificate.
What do NotBefore and NotOnOrAfter mean?
They define the time window in which the assertion may be accepted. Conditions NotBefore/NotOnOrAfter limit the whole assertion; SubjectConfirmationData NotOnOrAfter limits how long the bearer confirmation can be used, typically a few minutes. If the IdP and SP clocks differ, valid logins can fail; most libraries allow a small clock skew such as 1 to 5 minutes.
Why is my assertion shown as encrypted?
Some identity providers encrypt the assertion with the service provider's public key (EncryptedAssertion). Only the SP's private key can decrypt it, so the decoder can show the outer Response and status but not the user or attributes inside.
What does an InvalidNameIDPolicy or Requester status mean?
The status code tells you why login failed. Requester means the request from the SP was at fault; a second-level code such as InvalidNameIDPolicy means the requested NameID format is not supported for that app, and AuthnFailed means the user did not authenticate. Fix the SP request or IdP configuration and try again.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.