Decode and inspect SAML assertions, requests, and responses with XML formatting and attribute extraction.
SAML is how single sign-on passes proof of identity between an identity provider and a service provider, and in transit a SAML message is almost always base64. This tool takes that base64 blob, decodes it back to the XML document underneath, indents it so the nesting is readable, and extracts the parts that matter: the issuer, the NameID, the attribute name/value pairs, and the validity conditions. The thing people miss most often: a SAMLRequest or SAMLResponse copied from an HTTP-Redirect URL is usually still percent-encoded and, depending on the sender, may also be DEFLATE-compressed before the base64 step. Pasted verbatim it often shows as an error or binary garbage; percent-decode it, inflate if needed, and it decodes normally. Processing happens entirely in your browser, so the token never leaves your machine.
A concrete input and expected output from the current implementation.
Input
PHNhbWw6TmFtZUlEIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPmFsaWNlQGV4YW1wbGUuY29tPC9zYW1sOk5hbWVJRD4=
Expected output
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">[email protected]</saml:NameID>
The pasted string is the RFC 4648 base64 encoding of that exact XML fragment, so decoding reproduces the original markup character for character. A leaf element with no children stays on one line; the fragment contains no Subject, Conditions, or AttributeStatement for the extraction view, so the output is the XML alone.
In the common HTTP Redirect and POST bindings, a SAML 2.0 message travels base64-encoded, so the first step is reversing that encoding (RFC 4648) and parsing the result with an XML parser. The tool then re-serializes the parsed tree with indentation, so the nesting of AuthnRequest, Response, and Assertion elements becomes visible and the attributes on each element are easy to read.
After parsing, the tool walks the document for the standard SAML 2.0 structures: Issuer, Subject with its NameID and SubjectConfirmation, Conditions with NotBefore and NotOnOrAfter, AuthnStatement and AuthnContext, and every Attribute in an AttributeStatement with its Name, NameFormat, and AttributeValue. These appear as a compact list next to the formatted XML, so the claims the message carries are visible at a glance.
You almost certainly copied it from an HTTP-Redirect binding URL, where the message is percent-encoded and may be DEFLATE-compressed before being base64-encoded. Percent-decode it, decompress it if needed, and the base64 then decodes to XML. If the tool does not offer these steps itself, do them before pasting.
It is safe in the sense that the decoding runs entirely in your browser and nothing is uploaded. It is not a validator: signature, issuer trust, and the NotBefore/NotOnOrAfter window are not checked, so use it to read what a message contains, not to prove authenticity.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.