SAML Decoder
Decode and inspect any SAMLResponse or SAMLRequest — base64, DEFLATE-encoded redirect URLs, or raw XML. Read the assertion in plain English, catch expiry and clock-skew problems, and verify the signature — all in your browser.
What is a SAML message?
SAML 2.0 (Security Assertion Markup Language) is the XML-based standard behind most enterprise single sign-on. A service provider (SP) — your application — sends an AuthnRequest to an identity provider (IdP) such as Okta, Entra ID, or Keycloak. The IdP authenticates the user and sends back a Response containing a signed Assertion: who the user is (the NameID), which SP it is for (the Audience), how long it is valid, and the user's attributes.
Messages travel through the browser, so they are encoded to fit in a form field or URL. That encoding is not encryption — anyone holding the message can read it, which is exactly what this decoder does. For a gentle introduction, read SAML, simplified.
What you can paste
- HTTP-POST binding — the base64 value of the
SAMLResponseorSAMLRequestform field, or the whole form body includingRelayState. - HTTP-Redirect binding — a full URL such as
https://idp.example.com/sso?SAMLRequest=…&RelayState=…&SigAlg=…&Signature=…, or just the URL-encodedSAMLRequestvalue. The message is DEFLATE-compressed; the decoder inflates it. - Raw XML — a Response, AuthnRequest, LogoutRequest, LogoutResponse, a bare Assertion, or SAML metadata.
The format is detected automatically, and the decoder tells you which binding and encoding it found.
How to capture a SAML message from your browser
Open your browser's developer tools (F12, or Cmd+Option+I on macOS), switch to the Network tab, enable Preserve log, and sign in:
- For a
SAMLResponse, find the POST to the SP's Assertion Consumer Service URL (for a Keycloak broker,/realms/{realm}/broker/{alias}/endpoint) and copy theSAMLResponsevalue from the request payload. - For a
SAMLRequest, find the redirect to the IdP (for Keycloak as the IdP,/realms/{realm}/protocol/saml) and copy the full request URL.
Verify a SAML signature
Decoding shows what a message says; verification proves who sent it. Paste the IdP's signing certificate or its metadata into the verification panel. The decoder checks every enveloped XML signature — on the Response, the Assertion, or both — by canonicalizing the signed element, comparing its digest, and verifying the RSA or ECDSA signature with WebCrypto. For redirect URLs it also checks the SigAlg/Signature query-string signature. It flags duplicate IDs and misplaced signatures, the patterns behind signature-wrapping attacks.
Verify the message exactly as it was received: reformatting the XML, even just whitespace, invalidates the signature.
Debug SAML with Keycloak and Phase Two
When the message comes from or goes to Keycloak, the decoder recognizes the endpoint and translates common failures into the Keycloak setting that fixes them:
- Issuer vs. client ID — Keycloak looks up a SAML client by the AuthnRequest's Issuer, so the two must match exactly.
- Destination vs. ACS URL — the response Destination and SubjectConfirmationData Recipient must equal the SP's Assertion Consumer Service URL.
- Audience vs. entity ID — when Keycloak brokers an external IdP, the audience must be Keycloak's SP entity ID (the realm URL unless overridden).
- NameID format and clock skew — the identity provider's NameID policy format, principal type, and "Allowed clock skew" settings.
For setup details see Keycloak as an identity provider broker, configuring identity providers, identity provider mappers, and IdP-initiated SAML with Keycloak.
Compare a request with its response
Many SAML failures are mismatches between what the SP asked for and what the IdP sent back. Use Compare request & response with the AuthnRequest (or LogoutRequest) and the Response it produced. The tool checks InResponseTo against the request ID, the Destination and Recipient against the requested ACS URL, the Audience against the requesting SP's Issuer, the NameID format against the NameIDPolicy, the AuthnContextClassRef against the RequestedAuthnContext, and the ProtocolBinding against how the response actually arrived. A clock-skew tolerance setting mirrors your SP's allowed skew when checking validity windows.
More free tools
Working with OIDC too? The JWT Decoder decodes and verifies access and ID tokens. See all developer tools.
Frequently asked questions
Is it safe to paste a SAML response here?
Yes. Decoding, inflating, parsing, and signature verification all happen in your browser with client-side JavaScript and WebCrypto. The tool makes no network requests: your SAML messages and certificates are never sent to Phase Two or anyone else, logged, or stored. Open your browser's network tab while you decode to confirm.
How do I decode a SAMLResponse?
Paste the value of the SAMLResponse form field (base64), the whole POST body, or the raw XML. The decoder base64-decodes it, pretty-prints the XML, and summarizes the issuer, destination, NameID, audience, conditions, attributes, and status.
How do I decode a SAMLRequest from a redirect URL?
Paste the entire URL. With the HTTP-Redirect binding the SAMLRequest parameter is DEFLATE-compressed, base64-encoded, then URL-encoded. The decoder undoes all three steps, shows the RelayState, and, if the URL carries SigAlg and Signature parameters, can verify the query-string signature.
Can it verify a SAML signature?
Yes. Paste the IdP's X.509 signing certificate (PEM or bare base64) or its metadata XML. The tool canonicalizes the signed element (Exclusive C14N or C14N 1.0), checks the digest, and verifies the RSA or ECDSA signature with WebCrypto. It tells you whether the Response, the Assertion, or both are signed, and why a check failed.
Can it decrypt an encrypted assertion?
No. An EncryptedAssertion can only be decrypted with the service provider's private key, and you should never paste a private key into a web page. The tool detects encrypted assertions and tells you what it can about the message around them.
Why does my SAML response say it is expired?
SAML assertions are valid for a short window, set by Conditions NotBefore / NotOnOrAfter and SubjectConfirmationData NotOnOrAfter. The decoder compares them with your current time. A message captured a while ago will show as expired; a boundary missed by only seconds usually means the IdP's and SP's clocks disagree.
What does a Responder or InvalidNameIDPolicy status mean?
The top-level status says which side failed (Requester means the SP's request was the problem, Responder means the IdP). The second-level code says why — for example InvalidNameIDPolicy means the IdP cannot produce the NameID format the SP requested. The decoder explains every standard SAML 2.0 status code.
How do I check that a SAML response matches its request?
Switch to Compare request & response and paste both messages, in either order. The tool checks that InResponseTo equals the request ID, that the Destination and Recipient equal the requested ACS URL, that the Audience is the requesting SP's Issuer, that the NameID format and authentication context are what the SP asked for, and that the response came back over the requested binding.
Does it account for clock skew?
Yes. Set the clock-skew tolerance (in seconds) to mirror your SP's setting, such as Keycloak's Allowed clock skew on a SAML identity provider. Validity checks then accept timestamps that are off by up to that much, and say so.
Does it understand Keycloak?
Yes. It recognizes Keycloak realm SAML endpoints (/realms/{realm}/protocol/saml) and identity-broker endpoints (/realms/{realm}/broker/{alias}/endpoint), and points to the Keycloak setting behind common failures: client ID vs. issuer, audience vs. SP entity ID, NameID format, signature requirements, and allowed clock skew.