SAML Response/Request Decoder

Decode and inspect SAML Responses and Requests instantly. Auto-detects Base64, DEFLATE compression, and raw XML. Extracts issuer, subject, attributes, conditions, and X.509 certificate details.

Was this tool helpful?

How to Use

Decoding a SAML Response or Request takes just a few steps:

Capture the SAML message: Open your browser's Developer Tools → Network tab and trigger the SSO login flow. Find the POST request to the Assertion Consumer Service (ACS) endpoint and copy the SAMLResponse or SAMLRequest parameter value.
Paste the value: Drop the raw Base64 string (or URL-encoded Base64 string) into the input area. The tool auto-detects the encoding format.
Review the Summary tab: See the SAML message type (Response, Request, Assertion), issuer, subject NameID, conditions with validity status, user attributes, and signature details at a glance.
Inspect the Decoded XML: Switch to the Decoded XML tab for the full pretty-printed XML with proper indentation and namespace handling.
Check Certificates: If the assertion is signed, the Certificate tab shows X.509 certificate details including Subject CN, issuer, serial number, and validity dates.
Copy or share: Use the copy button to grab the decoded XML for further analysis in other tools or to share with your identity provider's support team.

About This Tool

Understanding SAML Message Decoding

SAML (Security Assertion Markup Language) is the dominant protocol for enterprise Single Sign-On (SSO), used by over 80% of organizations with more than 1,000 employees as of 2026. SAML 2.0 defines an XML-based framework where an Identity Provider (IdP) authenticates users and sends digitally signed assertions to a Service Provider (SP). These XML messages are encoded — typically Base64 with optional DEFLATE compression — making them unreadable without a decoder. This tool reverses that encoding to reveal the full XML structure and extracts the critical security fields that developers and IT administrators need during integration and troubleshooting.

SAMLResponse vs SAMLRequest Encoding

SAML uses two primary HTTP bindings that encode messages differently. The HTTP-Redirect binding (used for AuthnRequests) applies DEFLATE compression (RFC 1951) before Base64-encoding, because URLs have a practical length limit of approximately 2,000 characters. The HTTP-POST binding (used for Responses) only Base64-encodes the XML since POST bodies have no practical size limit. This decoder automatically tries both decompression pipelines — raw DEFLATE inflate, zlib inflate, and plain Base64 — so you never need to know which binding was used.

Key Fields Extracted from SAML Assertions

A SAML Response typically contains one or more Assertions, each carrying several critical elements. The Issuer (EntityID) identifies the Identity Provider that created the assertion. The Subject contains the NameID — the user's identifier, which may be an email address, persistent ID, or transient ID depending on the SP's configuration. The Conditions element defines the assertion's validity window with NotBefore and NotOnOrAfter timestamps, along with AudienceRestriction to prevent token replay against other services. The AttributeStatement carries user attributes like email, name, groups, and roles as name-value pairs. The AuthnStatement records how and when the user authenticated, including the AuthnContextClassRef that describes the authentication strength (password, multi-factor, certificate-based).

X.509 Certificate Analysis

SAML assertions are digitally signed using XML Signature (XMLDSig). The signing certificate is embedded in the assertion's <ds:X509Certificate> element as a Base64-encoded DER blob. This tool decodes that certificate to extract the Subject Common Name (CN), Issuer CN, serial number, and validity dates. Certificate rotation is one of the most common causes of SAML integration failures — comparing the certificate in the assertion against what your SP has configured is often the first step in debugging authentication errors.

Common SAML Debugging Scenarios

When SSO fails, the decoded SAML message reveals the root cause in most cases. A StatusCode of Requester or Responder instead of Success indicates the IdP rejected the request. Mismatched Audience values cause "invalid audience" errors. Expired Conditions timestamps (NotOnOrAfter in the past) trigger "assertion expired" failures, often caused by clock skew between IdP and SP servers. Missing or unexpected attributes in the AttributeStatement cause attribute mapping failures. And a changed X.509 certificate in the Signature element causes "signature validation failed" errors, which require updating the SP's certificate trust configuration.

Why Use This Tool

Why Use This SAML Decoder?

SAML tokens contain sensitive user identity data — email addresses, names, group memberships, and authentication context. Pasting these tokens into server-side decoder tools sends that data to a third party. This decoder runs entirely in your browser using the Web Crypto API and client-side JavaScript. Your SAML tokens are never transmitted, logged, or stored anywhere. You can verify this by monitoring the Network tab in your browser's developer tools during decoding.

Who Needs a SAML Decoder?

Identity engineers configuring SSO integrations with Okta, Azure AD, OneLogin, PingFederate, or ADFS.
Application developers implementing SAML SP endpoints and debugging attribute mapping.
Security teams auditing SAML configurations for certificate expiry, weak signature algorithms, or missing audience restrictions.
Support engineers troubleshooting "SSO not working" tickets by comparing expected vs actual assertion content.
Penetration testers analyzing SAML flows for vulnerabilities like XML Signature Wrapping (XSW) attacks.

Advantages Over Competitor Tools

Unlike samltool.io and similar server-side decoders, this tool provides instant auto-decoding as you type (no submit button required), structured metadata extraction with a clean summary view (not just raw XML), X.509 certificate parsing with validity dates, condition validity checking against your current system time, and a two-panel side-by-side layout that keeps input and output visible simultaneously. All of this runs with zero server dependencies and zero latency.

FAQ

What is the difference between SAMLResponse and SAMLRequest?

A SAMLRequest is sent by the Service Provider (SP) to the Identity Provider (IdP) to initiate authentication. It is typically DEFLATE-compressed and Base64-encoded. A SAMLResponse is sent by the IdP back to the SP after authentication, containing the SAML Assertion with user identity and attributes. Responses are usually Base64-encoded without DEFLATE compression.

Why does my SAML message need to be inflated or deflated?

SAML HTTP-Redirect bindings compress XML using DEFLATE (RFC 1951) before Base64-encoding to fit within URL length limits. HTTP-POST bindings typically only Base64-encode without compression. This tool auto-detects both formats and applies the correct decoding pipeline automatically.

Can I decode SAML messages from browser developer tools?

Yes. Open your browser's Network tab, find the SSO redirect or POST request, and copy the SAMLResponse or SAMLRequest parameter value. Paste the raw Base64 string into this tool. If the value is URL-encoded, the tool will automatically URL-decode it first.

Is it safe to paste SAML tokens into online tools?

This tool processes everything in your browser using JavaScript. No data is sent to any server. You can verify this by opening your browser's Network tab before decoding. For production tokens containing sensitive user data, client-side tools like this one are the only safe option.