SAML Decoder
Paste a SAML value, URL or form and see the XML and what it means, in your browser.
Try before you buy.
- Free preview: the message type, the decoding steps and every count, with the first rows of the summary (up to 10) and the first lines of the XML (up to 20).
- Locked until you unlock it: download and copy.
- Unlock: Pro pass, ₹179 for 30 days or ₹79 for 1 week, a one-time payment that never renews. Unlock: Pro pass, $5.99 for 30 days or $2.99 for 1 week, a one-time payment that never renews.
Ways to unlock shows how to get the full result.
Printing this result is locked in the free preview.
Decoded on your device as you paste — nothing is uploaded. A fresh SAMLResponse can grant access until it expires, so treat it like a password.
Summary
Locked in the free preview. Opens the ways to unlock this result.
Locked in the free preview. Batch runs unlock with a pass.
Locked in the free preview. Query results unlock with a pass.
About the SAML Decoder
Decode the SAML messages that single sign-on passes through your browser. Paste a SAMLRequest or SAMLResponse value, the whole URL of an HTTP-Redirect, a POST form body or the form data copied from your browser’s developer tools, or the HTML of the auto-submit page an identity provider returns — or open a HAR file saved from the Network panel. The transport is undone step by step — URL decoding, Base64, DEFLATE — and the XML is shown indented and readable.
A summary says what the message means: its type, issuer and destination, the requested or returned NameID, the audience, the validity window compared with your clock, the attributes, the authentication context and status, and every signature with its algorithms and certificate (subject, issuer, validity, fingerprints). It points out what often breaks or weakens SSO — an unsigned assertion, SHA-1, several assertions, a signature that refers elsewhere, an expired window. It does not verify signatures or decrypt encrypted assertions. Everything runs in your browser, which matters: SAML responses carry personal data and can grant access while they are valid.
Without a pass the result is a free preview: the message type, the decoding steps and every count, with the first rows of the summary and its notes and the first lines of the formatted XML. A Pro pass unlocks the whole result, with every copy and download, and the encoded value, URL and test form of the Encode tab.
How to use it
- Take the message from your browser’s developer tools: in the Network tab, the SAMLRequest is in the URL that goes to the identity provider; the SAMLResponse is in the form data of the POST to the service provider. Copying the whole URL, the form body or the parsed form data is fine, and a HAR file (“Save all as HAR”) can be opened as it is: its first SAMLResponse is shown.
- Paste it into the box. The value is decoded as you type, and the steps that were undone are listed.
- Read the summary: issuer, NameID, audience, validity, attributes and signatures. Warnings explain anything that a service provider is likely to reject or that weakens security.
- Read the formatted XML; with a pass, or after unlocking this result, copy it or download it.
- To build a test message, switch to Encode, paste or edit XML and choose the HTTP-Redirect or HTTP-POST binding; the value, a full URL or a test form is made for you to copy with a pass.
Examples
https://ServiceProvider.com/SAML/SLO/Browser?SAMLRequest=fVFdS8MwFH0f7D%2BUvGdNsq62oSsIQyhMESc…&RelayState=0043bfc1bc45110dae17004005b13a2b&SigAlg=…&Signature=…
Steps: URL parameter SAMLRequest → URL decoding → Base64 → raw DEFLATE LogoutRequest from https://IdentityProvider.com/SAML NameID 005a06e0-ad82-110d-a556-004005b13a2b (persistent), SessionIndex 1
PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wi…
Response · Success · 1 signed assertion NameID jane.doe@example.com (emailAddress) · Audience https://sp.example.com/metadata Conditions: valid now, ending a few minutes after the IdP issued them
Common uses
- Finding out why a single sign-on login fails: wrong audience, an expired assertion, a missing attribute, a status other than Success.
- Checking which attributes and NameID format an identity provider really sends before mapping them in an application.
- Seeing which certificate signed a response and when it expires, while rotating IdP certificates.
- Reading the AuthnRequest a service provider sends: ACS URL, binding, NameID policy, ForceAuthn and requested authentication context.
- Making a SAMLRequest URL or a POST test form from edited XML for a test environment.
- Reading the SAML messages in a HAR file that someone captured while their login failed.
- Reading WS-Federation tokens, SAML 1.1 assertions and SAML metadata, which use the same XML.
How the bindings carry a message
- HTTP-Redirect (Bindings §3.4.4.1): the XML is compressed with raw DEFLATE (no zlib header), Base64-encoded and URL-encoded into a
SAMLRequestorSAMLResponsequery parameter. Any XML signature is removed first; the URL is signed instead, withSigAlgandSignatureparameters overSAMLRequest=…&RelayState=…&SigAlg=…. - HTTP-POST (§3.5.4): the XML is Base64-encoded, without compression, into a hidden form field that the browser posts. Signatures stay inside the XML.
- HTTP-Artifact (§3.6.4): only a short reference,
SAMLart, travels through the browser; the receiver fetches the message directly. This tool shows the artifact’s parts — type code, endpoint index, SourceID (by the practice the bindings recommend, the SHA-1 of the issuer’s entity ID) and message handle. - RelayState, in both bindings, is opaque state for the service provider and may be at most 80 bytes.
Reading the times
SAML times are in UTC (they end in Z). An assertion is usable from NotBefore up to, but not including, NotOnOrAfter; the subject confirmation has its own NotOnOrAfter, and the session can end at SessionNotOnOrAfter. The summary compares each window with your device’s clock, so a few seconds’ difference from the server’s clock is normal — service providers usually allow some clock skew.
Limitations
- Signatures are not verified: that needs the identity provider’s trusted certificate and the exact canonical form of the signed XML. The summary only reports what the signatures say they cover.
- Encrypted assertions (EncryptedAssertion) cannot be read without the service provider’s private key; their algorithms are shown.
- An artifact (
SAMLart) is a reference, not the message: the message itself has to be fetched from the issuer. - The formatted XML changes whitespace, so it would no longer match a signature. To re-encode a signed message unchanged, encode the original XML.
Privacy
On this device: nothing is sent
Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.
Frequently asked questions
What do I get without a pass?
Without a pass, SAML Decoder shows the message type, the decoding steps and every count, with the first rows of the summary (up to 10) and the first lines of the XML (up to 20). Until you unlock it, the result can’t be downloaded or copied. A Pro, Premium or Ultimate pass, a one-time payment that never renews, unlocks the full result. The pricing page lists the passes and their prices.
Is it safe to paste a SAML response here?
The page does everything in your browser and sends nothing anywhere, and it works offline once loaded. Still treat a fresh SAMLResponse like a password: until NotOnOrAfter passes, someone who has it could try to replay it to the service provider.
Why does it say the value is neither XML nor DEFLATE-compressed XML?
The value was probably cut off — Redirect values are long, and copying often stops at a line break or an & — or it is not a SAML message at all. Copy the whole URL or the whole form field again.
Can it check the signature?
No. Verifying an XML signature needs the IdP’s certificate from a trusted source (its metadata, not the certificate inside the message) and byte-exact canonicalisation. Use your service provider’s SAML library or its logs for that; this tool shows the algorithms, what each signature refers to and which certificate it includes.
What is the difference between SAMLRequest and SAMLResponse?
A service provider sends a SAMLRequest (usually an AuthnRequest to start a login, or a LogoutRequest) to the identity provider. The identity provider answers with a SAMLResponse that carries the status and, after a login, the assertion about the user.
Why are there several assertions or signatures?
A response may be signed as a whole, its assertion may be signed, or both. More than one assertion is unusual: service providers must use only the assertion their signature check covered, because extra unsigned assertions are how signature-wrapping attacks work.