SAML debugging usually starts with an opaque Base64 blob in a browser network trace and a login that does not work. This decodes it so you can see what the identity provider actually sent.
Two bindings, two encodings
Choosing the wrong one is the first obstacle:
- POST binding — the assertion arrives as a form field, Base64-encoded. Choose "Base64".
- Redirect binding — the assertion arrives as a query parameter, raw-deflated and then Base64-encoded. Choose "Base64 + deflate".
If Base64 produces binary garbage, it is deflated. This tool uses the browser's native DecompressionStream, so no library is involved.
What to read first
Destination must match your assertion consumer service URL exactly. A mismatch here is the single most common SAML failure, and the error the service provider returns rarely says so.
Audience must match your entity ID exactly, including the scheme and any trailing slash. The second most common failure.
NotBefore and NotOnOrAfter define a validity window that is typically five minutes wide. If your clocks drift, valid assertions get rejected intermittently — which presents as "SSO works for some people sometimes".
NameID is the subject identifier, and its format matters. A transient NameID is different on every login and cannot be used to key an account. A persistent or email-format NameID is stable.
Attribute statements carry group memberships, roles and email. This is where you find out that the IdP is sending http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress while your service provider expects email.
Signature: presence, not validity
This parser reports whether a <Signature> element exists. It does not verify it, and that limitation is deliberate rather than an omission.
Verifying an XML signature requires canonicalisation (C14N), reference resolution and transform processing. Getting it subtly wrong produces the signature-wrapping attacks that have affected many SAML implementations: the verifier checks one element while the application reads another, so an attacker appends their own assertion to a legitimately signed document and both checks pass.
Always verify SAML signatures server-side with a maintained library. Never hand-roll it, and never trust a browser tool's claim that a signature is valid.
Frequently asked questions
Is it safe to paste a real SAML response here?
The parsing runs in your browser and nothing is transmitted. Note that an assertion contains real identity data about a real person, so handle it as you would any personal data — but it is not being sent anywhere.
Why does my assertion fail with no useful error?
Check Destination and Audience first; between them they account for most failures. Then check the validity window against your server's clock. Then check that the IdP's signing certificate matches the one your SP has configured — a certificate rotation at the IdP breaks every SP that was not told.
Can I use this to verify an assertion is authentic?
No. It reports whether a signature element is present, which is not the same as valid. Signature verification belongs server-side, in a maintained library.
SAML or OIDC for a new integration?
OIDC, unless an enterprise customer requires SAML — which many still do. OIDC is JSON over HTTPS with a much smaller attack surface; SAML is XML with a signature model that has produced a long history of bypasses.