SAML Decoder: complete usage guide
Decode SAML requests and responses locally to inspect assertions, issuer metadata, subject identifiers, conditions, attributes, and signature material before debugging IdP/SP integration issues.
What this tool does
It accepts raw XML, Base64 POST binding payloads, or URLs containing SAMLResponse or SAMLRequest parameters.
It extracts issuer, NameID, audience, recipient, destination, condition timestamps, attributes, signature count, and embedded certificate count.
It keeps the decoded XML visible for local review while making the summary table easier to scan during incident response.
It explicitly separates decoding from trust validation, so teams do not mistake parsed fields for a verified login decision.
Typical use cases
- Debug SSO login failures caused by audience or recipient mismatches.
- Inspect SAML attributes before mapping them into application roles.
- Review assertion timing values while diagnosing clock skew or expired sessions.
- Compare IdP output against SP configuration without uploading assertions to third-party tools.
- Prepare redacted SAML examples for support tickets and runbooks.
Input examples
POST binding payload
Base64 SAMLResponse copied from a browser form post.
Raw XML
<samlp:Response>...</samlp:Response>
URL parameter
https://sp.example.com/acs?SAMLResponse=...
Output examples
Summary table
Issuer, NameID, audience, recipient, conditions, signatures, and certificates.
Attribute list
role=admin, department=engineering, email=alice@example.com
Decoded XML
Pretty reviewable XML for local inspection and redaction.
Common errors and fixes
Compressed Redirect binding pasted as Base64
Use POST binding payload or raw XML for this MVP; compressed Redirect payloads are detected but not inflated.
Audience does not match SP entity ID
Compare the Audience value with your service provider configuration.
Recipient points to the wrong ACS URL
Check SubjectConfirmationData Recipient against the expected ACS endpoint.
Assertion appears expired
Review NotBefore and NotOnOrAfter with IdP and SP clocks in mind.
Treating decoded XML as verified
Use platform-level signature and trust validation before accepting any authentication result.
Security and privacy notes
For the shared privacy terminology, local processing model, external-request labels, and DevTools verification workflow, see the Trust Center.
- SAML decoding runs entirely in the browser.
- Assertions can contain user identifiers, group names, and session data; redact before sharing.
- This tool does not contact your IdP, SP, or certificate authority.
Step-by-step workflow
- Feed SAML Decoder the smallest reproducible sample you can collect from the real issue.
- Review the first findings and separate confirmed signals from assumptions or environment-specific noise.
- Compare a clean baseline sample against the problematic input when you need to isolate regressions.
- Keep one redacted output snapshot with the key findings for tickets, runbooks, or incident handoff.
Quality checklist before sharing output
- Confirm SAML Decoder findings still reproduce with the same input and assumptions.
- Check that the sample includes enough surrounding context to support the conclusion you are drawing.
- Translate notable findings into concrete next checks, ownership, or remediation notes.
- Redact private hosts, tokens, certificates, or customer identifiers before sharing analysis output.
Operational notes
SAML Decoder is most effective when it produces a focused, reproducible evidence bundle that can be handed to the next engineer without extra cleanup.
Frequently asked questions
Does this validate SAML signatures?
No. It decodes and summarizes SAML XML only; signature trust must be verified by your SAML runtime.
Can it read SAMLResponse form values?
Yes. Paste the Base64 value directly or a URL/query containing SAMLResponse.
Does it support compressed Redirect binding?
It detects likely compressed payloads and warns, but the MVP focuses on raw XML and Base64 POST binding.
Is the assertion uploaded?
No. Decoding and parsing happen locally in your browser.
What fields should I check first?
Issuer, audience, recipient, condition timestamps, NameID, and expected attributes usually explain most SSO mismatches.
