THE PRACTICAL GUIDE · NORMANDIN SYSTEMS
Get more from SAML Parser
SAML Parser: Detects SAML input (Base64, DEFLATE, or XML), parses, validates its signature, and displays a structured view of the assertion—including issuer, subject, conditions, authentication context, claims, and validation status. SAML inspection helps separate assertion content from the trust and time conditions used by a service provider during authentication. Parsing turns structured input into fields that are easier to inspect. It can reveal what a message or file says, but it does not automatically prove that the source is trustworthy or that an associated action succeeded. Preserve the original input while investigating and compare extracted values with the surrounding system’s expectations. Incomplete copies, altered line endings, and missing wrappers can prevent otherwise valid content from parsing. Start with a representative sample, inspect the fields most relevant to your question, and keep any validation result separate from the decoded content itself.
Guide updated October 13, 2026
How to use this tool
- Begin with a representative input. For a practical test, use: A sample SAML assertion in XML or supported encoded form. Replace demonstration values only after you understand the output.
- Provide the complete supported input, including its structural headers or wrappers where required, rather than copying only a visible fragment.
- Inspect the extracted fields and any parsing or validation errors, comparing them with the system that produced the source.
- Save the relevant findings with their context and confirm operational conclusions using the authoritative application or service.
SEE IT IN PRACTICE
A worked example
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_demo" Version="2.0" IssueInstant="2026-01-01T00:00:00Z"><saml:Issuer>https://idp.example</saml:Issuer><saml:Subject><saml:NameID>demo@example.com</saml:NameID></saml:Subject><saml:Conditions NotBefore="2026-01-01T00:00:00Z" NotOnOrAfter="2026-01-01T00:05:00Z"><saml:AudienceRestriction><saml:Audience>https://sp.example</saml:Audience></saml:AudienceRestriction></saml:Conditions></saml:Assertion>
Structural fields identify issuer https://idp.example, subject demo@example.com, and audience https://sp.example. Signature validation must not succeed: this deliberately minimal example is unsigned and its stated validity window is historical.
Use this only to distinguish readable assertion content from acceptance. The tool may report a validation error rather than render all fields. A real assertion needs the full structure and trust checks expected by the service provider.
Treat the assertion as a security message
A SAML assertion can contain a subject, authentication context, attributes, and conditions. These fields serve different purposes. An email attribute may be useful to an application, but the service provider also needs to validate that the message came from a trusted identity provider and was intended for this flow. Keep decoded content and validation status visibly distinct during debugging.
Diagnose mismatches systematically
Compare issuer and audience values exactly with the configured integration, then check timestamps and the signing certificate or key. Encoded transport forms may involve Base64 and compression, so preserve the original input while inspecting the XML. Bypassing expiration can help examine an old sample, but it changes the validation question. Do not carry a debugging bypass into an authentication decision.
When this tool is useful
- Inspect an SSO test assertion
- Review audience and conditions
- Debug claim mappings
Tips for a better result
- Do not bypass expiration or omit trust inputs and then interpret a readable assertion as a valid login.
- A parsed value is a representation of supplied data; it does not by itself establish identity, authenticity, or successful delivery.
- Keep an original copy for troubleshooting because removing headers or reformatting a payload can change what the parser sees.
Frequently asked questions
Which SAML fields matter beyond the visible user claims?
Issuer, audience, recipient or destination, validity conditions, and signature trust all affect acceptance. Visible claims alone do not establish that an assertion is suitable for the service provider.
Can decoded information be trusted automatically?
No. Decoding and trust are separate questions. Check signatures, source context, and application-specific validation where relevant, and do not treat a readable field as proof that its claimed sender or meaning is genuine.
What is the best way to report a parsing issue?
Create a small reproducible sample with sensitive values replaced carefully, preserve its structure, and note the expected format. Include the relevant error rather than sharing a full production message unnecessarily.
What happens to the information I enter?
The utility processes your input in this browser. Some tools retain field values in browser storage or the URL; avoid entering secrets in shareable fields. Page and asset requests still go to the hosting provider. Read the privacy and offline-use notes for details.