gizmobench

SAML Decoder

Paste a SAMLRequest or SAMLResponse, the whole Redirect URL that carries one, or the XML itself. The decoder finds and removes each layer the binding added (URL escapes, Base64 and raw DEFLATE), lists the ones it found, and reads the XML with its own bounded parser: a DOCTYPE or entity declaration is refused, scripts and processing instructions are removed, and nothing named in the message is ever requested. You get a tree you can open row by row, the key fields, every SAML attribute with its values, and each IssueInstant, NotBefore, NotOnOrAfter, AuthnInstant and SessionNotOnOrAfter compared with your device clock. NameID, attribute values, addresses and session indexes are redacted by default in the tree, the key fields, the attributes table and the XML you copy or download.

Your input

Decoded in this tab and never sent anywhere. The pasted text stays in memory and is not saved; only the decode path, output format and redaction choices are remembered. Ctrl or Cmd with Enter decodes.

Result

  1. 1. URL decode
  2. 2. Base64
  3. 3. raw DEFLATE

In Auto, each layer is applied only when the text needs it. The XML inside appears here as a tree you can open row by row.

No signature check. DTDs and entity declarations are refused, scripts are removed, and nothing is fetched.

Paste a SAMLRequest or SAMLResponse value, a URL that carries one, or SAML XML, then press Decode.

Layers applied
Not decoded
Pasted characters
0
XML bytes
Not decoded
Blocked constructs
Not decoded

Common questions

Does this SAML decoder verify the signature?
No. Decoding only reverses the encoding, so anyone holding a SAML message can read it, signed or not. The decoder shows where each ds:Signature element sits and the signature algorithm, digest algorithm and reference it names, and it notes a Signature parameter in a Redirect URL, but it checks none of them. Verifying a signature needs the identity provider's certificate and XML canonicalization, and that belongs in the service provider that consumes the message.
What is the difference between the Redirect and POST bindings?
The HTTP-Redirect binding compresses the XML with raw DEFLATE, encodes it as Base64 and URL-encodes it into a SAMLRequest or SAMLResponse query parameter. The HTTP-POST binding only encodes the XML as Base64 in a form field. Auto detects which layers are present. Choose Redirect binding or POST binding to require one path; when the forced path does not fit, the error names the one that does.
Does a pasted SAML message leave this page?
The message is decoded in this browser tab, in a background worker where the browser allows one, and the page sends nothing from it anywhere. The pasted text is not saved: only the decode path, output format and redaction choices are remembered in this browser. A real response still identifies a person, so NameID, attribute values, addresses and session indexes are redacted by default.
Why was my XML refused because of a DOCTYPE?
A DOCTYPE brings a DTD, and DTDs carry the entity declarations behind XML external entity (XXE) and entity-expansion attacks. SAML messages do not use them, so this decoder refuses any document with a DOCTYPE or another markup declaration instead of parsing it. Without a DTD only the five predefined XML entities and numeric character references are expanded, and any other entity reference is refused with its line and column.
Why does decoding stop at 10 MB?
DEFLATE can shrink repetitive data about a thousandfold, so a short pasted value can expand into gigabytes. The decoder expands in small steps and stops as soon as the output passes 10 MB (10,485,760 bytes), with an error and no partial XML. Pasted text is limited to 2 MB, and XML nested more than 64 levels deep or holding more than 100,000 nodes is refused the same way. Real SAML messages are usually a few kilobytes.
What exactly does redaction change?
With the first toggle on, which is the default, the text of NameID, AttributeValue and SessionIndex elements and the Address, DNSName and SessionIndex attributes become [redacted] in the tree, the key fields, the attributes table and the XML you copy or download. The second toggle does the same for SignatureValue, DigestValue, X509Certificate and CipherValue. Attribute names, issuers, audiences and timestamps stay readable.
What is the difference between Indented and As decoded?
Indented rebuilds the XML two spaces per level, which is easier to read but changes the whitespace between elements. As decoded is the decoded text itself, character for character, apart from redacted values and the scripts, event handler attributes, script URLs and processing instructions the decoder removes. Use As decoded when whitespace matters, for example when comparing with what a signature covered.
Can it read an EncryptedAssertion?
No. An EncryptedAssertion can only be decrypted with the service provider's private key, which this page never asks for. The decoder lists where each encrypted element sits, so you can confirm that the identity provider encrypted the assertion, and the tree shows its CipherValue unless the second redaction toggle is on.
What do NotBefore and NotOnOrAfter mean?
They bound the window in which an assertion or its subject confirmation may be accepted. The timestamps table reads each value as UTC, shows how far it was from this device's clock when you decoded, and says whether NotBefore had been reached and whether NotOnOrAfter had passed. A value written with a UTC offset or without a time zone is flagged, because SAML expects UTC ending in Z. A service provider applies its own clock skew allowance, so a value a few seconds out can read differently there.

Decoding is not signature validation, identity verification or authorization. No remote endpoint calls.