WebToolVerseWebToolVerse

SAML Decoder

Processed locally — token never leaves browser

Decode and inspect SAML 2.0 Responses and Assertions. Accepts raw XML, Base64-encoded, or URL-encoded SAML. Client-side only.

SAML Input

Runs entirely in your browser — nothing is uploaded

Next steps

JWT Decoder

Decode JWT tokens and inspect header, payload, claims, and expiry instantly.

Base64 Converter

Encode or decode Base64 in one click — works with text and files.

XML Formatter

Beautify, validate, and minify XML. Convert between XML and JSON.

URL Encoder / Decoder

Percent-encode and decode URLs and URL components. Supports encodeURIComponent and encodeURI.

View all tools →
Runs entirely in your browser. No uploads. Your files stay private.

What Is SAML?

SAML (Security Assertion Markup Language) 2.0 is an XML-based standard ratified by OASIS in 2005 for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It is the backbone of enterprise single-sign-on for products like Okta, Azure AD / Entra ID, OneLogin, Ping, ADFS, Shibboleth, and Auth0's enterprise tier. Despite OIDC's growing share, SAML is still the dominant SSO protocol inside corporate networks.
A SAML Response is a Base64-encoded XML document POSTed by the IdP to the SP's Assertion Consumer Service (ACS) URL. The HTTP-POST binding wraps the Base64 string in a form field named SAMLResponse; the HTTP-Redirect binding additionally DEFLATE-compresses and URL-encodes the payload. This decoder accepts all three shapes: raw XML, URL-encoded XML, and Base64 (with optional URL-safe replacements of - and _ for + and /).
Decoding works in three steps. The browser's built-in atob() function reverses the Base64 alphabet (after this tool repads the string to a multiple of four with =). decodeURIComponent unwraps URL escapes if present. Then a small regex-based parser extracts the SAML-specific fields: Issuer, Destination, IssueInstant, NameID and its Format, the StatusCode value, and every Attribute name-value pair inside the AttributeStatement. The pretty-printer is a depth-tracking indenter rather than a real XML formatter, which keeps the bundle small at the cost of being lenient about malformed input.
An important boundary: this tool decodes, it does not verify. SAML's security guarantees come from the XML Signature (XMLDSig) wrapping the Assertion or the Response. Verifying that signature requires the IdP's public X.509 certificate, the SP's expected audience and ACS URL, and an XML canonicalization library — all of which belong on the server. Real SP libraries like passport-saml, saml2-js, python3-saml, and OneLogin's SAML SDK do this with care, including defenses against XML signature wrapping (XSW) attacks. Treat the decoded fields as informational.
Common operational issues that show up clearly here. Clock skew between IdP and SP causes NotBefore / NotOnOrAfter rejections — IssueInstant tells you what the IdP thinks the time is. Audience-restriction failures appear when the Audience element does not match the SP's EntityID. NameID-format mismatches (the SP expects emailAddress but the IdP sends persistent) show up in the Format attribute. Attribute-name mismatches (Email vs email vs http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress) are visible in the Assertion Attributes table.
Be aware of SAML's known vulnerabilities. Signature wrapping attacks rearrange the XML so a verifier signs one element but trusts another; XML External Entity (XXE) attacks exploit DOCTYPE processing in poorly configured parsers; the alg=none equivalent for SAML is accepting an unsigned assertion. None of these matter for read-only decoding, but they are critical when implementing the SP side. Keep your SAML library current and follow the OWASP SAML cheat sheet.
Everything happens in your browser. The SAMLResponse, which often contains real user identifiers and roles, is never sent to a server. Closing the tab discards it. Even so, treat captured production responses as sensitive — the attributes can include email, employee ID, group memberships, and entitlements that you do not want pasted into shared chat or screenshots.

Common Use Cases

01

SSO integration debugging

Decode SAMLResponse from your browser's network tab during IdP-SP setup to confirm attributes, NameID, and audience.

02

Failed-login triage

Read the StatusCode and Issuer to distinguish authentication failures (Responder), audience mismatches, and clock-skew rejections.

03

Attribute mapping verification

Confirm exactly which attribute names the IdP emits before wiring them to user fields in your SP.

04

NameID format conflicts

Spot when an IdP is sending persistent or transient identifiers when the SP expects emailAddress.

Frequently Asked Questions

Open browser DevTools, switch to the Network tab, enable Preserve Log, and trigger a fresh login. Look for a POST to your SP's ACS URL — the form payload contains a SAMLResponse field with the Base64 string. Some IdPs use a redirect binding instead; in that case the value is in the URL.
No, and it should not. Signature verification requires the IdP's public certificate, XML canonicalization, and careful handling of signature-wrapping attacks. Use a real SAML library on the server (passport-saml, python3-saml, OneLogin SDK) for verification.
Yes. AuthnRequest, LogoutRequest, and LogoutResponse are all XML and use the same encoding wrappers. The field-extraction regexes target Response-specific elements, so AuthnRequest output will show fewer named fields but the pretty XML still helps.
The Response is the outer envelope the IdP sends to the SP. It contains a Status and one or more Assertions. The Assertion is what the SP actually trusts; it carries the Subject (NameID), Conditions (audience, validity window), and the AttributeStatement.
SAML mandates xs:dateTime values in UTC with a Z suffix. Clock skew between the IdP and SP is the most common cause of the 'NotBefore' / 'NotOnOrAfter' rejections you see in logs — synchronize both sides to NTP.
It is the successful StatusCode value. Common failure codes include Responder (the IdP could not authenticate), Requester (the SP sent a malformed request), VersionMismatch, and AuthnFailed. Status text and a sub-status give more detail.
An attack class where an attacker rearranges the SAML XML so the signature still validates over one element but a different element is consumed by the SP. SP libraries protect against this by anchoring the signature to a specific Assertion ID and rejecting movement. It is one of the strongest reasons to never roll your own SAML verifier.
If you copied SAMLResponse from a HTTP-Redirect URL, it is likely DEFLATE-compressed before Base64. This tool does not currently inflate raw DEFLATE; copy the value from a HTTP-POST binding (the form body, not the URL) for the cleanest decode.
No. The Base64 input, decoded XML, and extracted fields all live in component state. Nothing is sent to a server, logged, or persisted between sessions.
Only with caution. SAML attributes commonly include email, employee ID, department, and role memberships. Redact those fields before pasting into a public ticket or chat.

Advertisement