SAML Inspector

Decode a SAMLResponse or AuthnRequest and see who it logs in, for which service and until when — with checks for unsigned assertions, signature wrapping and comment tricks.

Runs entirely in your browser. Your browser blocks this page from opening connections or loading anything from other sites. Nothing you enter is uploaded or saved.

requests since opened: 0
How to verify this yourself
  1. Open your browser’s developer tools (F12, or ⌥⌘I on Mac) → Network tab, then use the tool. No new requests appear.
  2. Or disconnect from the internet after the page loads — the tool keeps working, because it never needed the network.
  3. See the rule itself: in the Network tab, select this page’s document → Response Headers → content-security-policy contains connect-src 'none' and no 'unsafe-inline' for scripts.
  4. Press Test the lock: the page tries a harmless request and the browser blocks it (the Console shows the refusal).
How to use
  1. Paste the SAMLResponse (Base64), a SAML URL, or the XML — from your browser’s network tab or a SAML tracer.
  2. Read the user, audience, time window and the findings.
  3. Enter your SP’s entity ID and ACS URL for a clear accept / reject.

Common questions

How do I get the SAMLResponse to decode?

In your browser’s developer tools, open the Network tab, sign in, and find the POST to your application’s ACS URL: the SAMLResponse form field is the value to paste. A SAML tracer extension shows it too.

Why does my SAML login fail?

The most common causes are an audience that doesn’t match the SP entity ID, a wrong ACS (Recipient) URL, clock skew between servers, and a changed IdP signing certificate. “Check it like your SP” tests each of these.

Does this verify the SAML signature?

It finds the signatures and checks them for the structural attacks behind real breaches (signature wrapping, unsigned assertions, comment truncation). Verifying the cryptography needs the IdP certificate in your SP.

Known limitations

  • Signatures are located and checked for structural attacks, but not cryptographically verified (that needs XML canonicalisation and the IdP’s certificate in your SP).
  • Encrypted assertions cannot be read: they need the SP’s private key, which should never be pasted into a website.
  • SAML 2.0 only. Messages with a DOCTYPE are refused on purpose (XML entity attacks).
  • Browser extensions with access to this site can read the page. For sensitive data, use a private window with extensions off. How the lock works

tools v0.9.0 · build 7317bbb · 2026-10-07

Related reading on CipherMind

Standards & references