SAML Decoderv2.0Enterprise SAML 2.0 Toolkit
Private & Real-Time SAML 2.0 Studio|Replaces Slow, Insecure Legacy Tools

Decode, inspect, & test SAML tokens with zero latency.

Instantly inflate, decode, and format Base64 SAML requests and responses. Extract user claims, inspect X.509 certificates, and validate assertions — 100% in your browser without ever exposing PII to external servers.

Auto Format Detection
HTTP-Redirect Deflate / Inflate
X.509 Cert & Fingerprints
Claims & Attributes Table
SP & IdP Metadata Studio
0 characters · 0 bytes100% in-browser parsing

Awaiting SAML Payload

Paste a Base64 string, URL-encoded redirect query, or XML on the left, or load one of the quick samples above.

X.509 Tool

X.509 Certificate Inspector & Fingerprint Calculator

Inspect signing and encryption certificates used in SAML 2.0 assertions. Verify expiration dates, calculate SHA-1 & SHA-256 thumbprints, and download clean PEM certificates.

Parsed locally using WebCrypto and standard ASN.1 decoder. Zero private data transmitted.

No Certificate Loaded

Paste a certificate on the left or click "Load Sample Cert".

Metadata Studio

SAML 2.0 Metadata Inspector & SP Generator

Inspect entity descriptors, SSO/SLO endpoints, and certificates from IdP/SP metadata XML. Need to integrate a new application? Generate standard SAML 2.0 SP metadata in seconds.

No Metadata Parsed

Paste XML on the left or click "Load Sample SP Metadata".

Comprehensive SAML Guide

The Complete Guide to SAML Decoding, Assertions, and XML Formatting

Learn how a modern SAML decoder works, how to url decode and inflate tokens, and inspect real-world saml assertion examples with instant xml pretty print formatting.

What is a SAML Decoder and Why Do Engineers Need It?

In modern enterprise identity architectures, Security Assertion Markup Language (SAML 2.0) serves as the foundational protocol powering federated Single Sign-On (SSO). When employees log in to SaaS applications via Identity Providers (IdPs) like Okta, Microsoft Entra ID (Azure AD), Google Workspace, or PingIdentity, authentication data is exchanged via cryptographically signed XML documents.

However, SAML messages are rarely transmitted across the network as plain XML. To prevent transport corruption, bypass header size limits, and conform to browser specifications, XML payloads are compressed using raw DEFLATE algorithms, converted into Base64 binary strings, and frequently URL-encoded into query parameters. When an authentication flow fails, engineers need a reliable saml decoder to reverse this multi-layer encoding process.

Our free online saml decoder allows developers to seamlessly decode saml requests and responses in real time. Rather than running manual terminal scripts or risking data exposure on third-party servers, our tool automatically detects input formats, inflates compressed streams, and applies structured xml pretty print styling in milliseconds.

How to Decode SAML: The Multi-Step Encoding Pipeline

To effectively saml decode a payload captured from browser developer tools, proxy traces, or audit logs, it is essential to understand the three primary stages of data transformation applied during SSO authentication:

Step 1

URL Decode

When SAML tokens pass through HTTP query strings, characters like + and = are percent-encoded. You must first url decode the string to restore clean Base64 characters.

Step 2

Base64 & Inflate

The string is converted from Base64 into binary bytes. For HTTP-Redirect, it is decompressed using the RFC 1951 raw Deflate algorithm. For HTTP-POST, it unpacks directly into XML text.

Step 3

XML Pretty Print

Raw decoded XML typically arrives as a dense single line. Applying automated xml pretty print indents tags, colors attributes, and makes the assertion immediately readable.

Manually performing each transformation in a terminal is slow and error-prone. Our intelligent saml decoder detects whether your input requires an initial url decode step, recognizes deflate streams, and presents a visual dashboard alongside syntax-highlighted code instantly.

SAML Request Decoder vs SAML Response Decoder: Understanding the Bindings

A frequent challenge when integrating Single Sign-On is distinguishing between authentication requests and responses. Depending on the direction of authentication, you will need either a saml request decoder or a saml response decoder:

1. The SAML Request Decoder (AuthnRequest via HTTP-Redirect)

In an SP-Initiated SSO workflow, your application initiates authentication by redirecting the user's browser to the Identity Provider via an <samlp:AuthnRequest>. Because query parameters have strict length limits in browser URLs, the specification requires raw RFC 1951 Deflate compression before Base64 encoding. Our saml request decoder inflates this stream transparently, revealing parameters like AssertionConsumerServiceURL, ForceAuthn, and NameIDPolicy.

2. The SAML Response Decoder (Assertion via HTTP-POST)

After user verification, the IdP sends the user back to the SP's ACS endpoint via an auto-submitting POST form containing a <samlp:Response>. Because HTTP POST bodies do not have URL length constraints, the XML is directly Base64-encoded without deflation. A dedicated saml response decoder extracts authentication status, user profile claims (email, name, roles), and inspects the digital signature.

Our unified studio works as both a high-speed saml request decoder and an enterprise saml response decoder, automatically handling both HTTP-Redirect and HTTP-POST bindings seamlessly.

Anatomy of a Real-World SAML Assertion Example

To visualize what our tool analyzes, consider this authentic saml assertion example generated during a successful Single Sign-On session:

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="id_assert_83921048" IssueInstant="2026-09-17T09:00:00.000Z" Version="2.0">
  <!-- 1. Identity Provider Entity ID -->
  <saml2:Issuer>http://www.okta.com/exk8172938172948</saml2:Issuer>
  
  <!-- 2. Authenticated User Identity (Subject) -->
  <saml2:Subject>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">alex.morgan@enterprise.com</saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData NotOnOrAfter="2026-09-17T09:05:00.000Z" Recipient="https://app.example.com/saml/acs"/>
    </saml2:SubjectConfirmation>
  </saml2:Subject>

  <!-- 3. Validity Window & Target Audience Restriction -->
  <saml2:Conditions NotBefore="2026-09-17T08:55:00.000Z" NotOnOrAfter="2026-09-17T09:05:00.000Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>https://app.example.com</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>

  <!-- 4. User Profile Claims & Enterprise Attributes -->
  <saml2:AttributeStatement>
    <saml2:Attribute Name="email"><saml2:AttributeValue>alex.morgan@enterprise.com</saml2:AttributeValue></saml2:Attribute>
    <saml2:Attribute Name="firstName"><saml2:AttributeValue>Alex</saml2:AttributeValue></saml2:Attribute>
    <saml2:Attribute Name="roles"><saml2:AttributeValue>Administrator</saml2:AttributeValue></saml2:Attribute>
  </saml2:AttributeStatement>
</saml2:Assertion>

In this saml assertion example, four essential elements are extracted and visualized:

  • Issuer: Identifies the exact Identity Provider tenant that generated and signed the assertion. A mismatch here is the leading cause of SSO validation rejections.
  • Subject / NameID: The primary unique identifier for the user (such as their corporate email).
  • Conditions (NotBefore & NotOnOrAfter): The strict time window (typically 5 minutes) during which the assertion remains valid. Our tool features a live clock skew meter indicating validity status.
  • AttributeStatement: The payload carrying user metadata (email, first name, roles, groups) used for Just-in-Time (JIT) account provisioning.

The Vital Role of XML Pretty Print in Security Audits

When identity providers construct SAML responses, XML tags are compressed onto a single line to minimize packet transmission size. When troubleshooting production authentication failures, attempting to locate an audience URI or signature block in an unformatted 10,000-character line is frustrating.

Applying clean xml pretty print formatting transforms minified markup into a clear structure with 2-space indentation. This is critical for both readability and security audits:

  • Detecting Signature Wrapping (XSW) Attacks: Formatting makes it immediately apparent if an assertion has been duplicated or if signed trees have been tampered with.
  • Verifying Canonicalization: Ensures standard algorithms like xml-exc-c14n# are configured correctly.
  • Auditing X.509 Certificates: Allows instant inspection of embedded public signing certificates within <ds:X509Certificate> blocks.

Privacy-First SAML Decoding: Why In-Browser Processing Matters

A vital consideration when you decode saml messages is data confidentiality. Production SAML assertions contain sensitive Personally Identifiable Information (PII) — including employee email addresses, internal directory group memberships, session identifiers, and organizational entity URIs.

Older legacy tools (such as SAMLTool.com) process messages using server-side PHP scripts. Every time a developer clicks "Decode" on those websites, real corporate credentials are sent over the internet to a third-party server. For enterprises bound by GDPR, SOC 2, HIPAA, or ISO 27001 compliance, transmitting production authentication tokens to external servers is a critical security violation.

SAMLDecoder.com is built with a zero-transmission guarantee: every cryptographic operation, deflate inflation, url decode step, and xml pretty print transformation runs 100% locally in your browser via native WebCrypto and JavaScript. No payload ever leaves your device.

Developer Reference

SAML 2.0 Developer Cheat Sheet & Troubleshooting

Essential protocol details, binding comparisons, and fixes for the most common single sign-on integration pitfalls.

HTTP-Redirect vs HTTP-POST

Understanding encoding differences is critical when debugging SAML messages:

  • •HTTP-Redirect (AuthnRequest, Logout): Deflated (RFC 1951 raw deflate) → Base64 → URL-encoded as a query param (?SAMLRequest=...).
  • •HTTP-POST (SAML Response, Assertion): Plain XML → Base64 encoded inside an HTML form field (name="SAMLResponse"). Not deflated!

Digital Signatures (XMLDSig)

How trust and integrity are guaranteed in SAML 2.0 assertions:

  • •Message vs Assertion Signing: The IdP can sign the outer <samlp:Response>, the inner <saml:Assertion>, or both.
  • •Canonicalization: Usually xml-exc-c14n# ensures signature consistency regardless of whitespace or attribute order.
  • •Algorithms: Modern IdPs (Okta, Entra ID) use rsa-sha256. Legacy SHA-1 signatures are deprecated.

Conditions & Clock Skew

Preventing replay attacks and dealing with timing mismatches:

  • •NotBefore & NotOnOrAfter: Defines the narrow window (typically 5 minutes) during which the assertion is valid.
  • •Clock Drift: Servers must allow a tolerance (recommended 2-3 minutes) to account for minor time discrepancies between IdP and SP servers.

Common SAML SSO Errors & Solutions

ErrorAudienceRestriction Mismatch

The SP rejected the assertion because the <Audience> does not match the SP's configured Entity ID. Verify that the IdP's Audience URI configuration matches your SP EntityID exactly (including trailing slashes).

ErrorSignature Validation Failed

The SP cannot verify the XML digital signature. Common causes: the IdP rotated its certificate and the SP still has the old one; the XML was altered by a proxy/gateway; or the signature is on the Assertion but the SP expects the Response to be signed.

ErrorAssertion Expired / Timing Issue

Current server time is outside the NotBefore and NotOnOrAfter timestamps. Synchronize both servers using NTP (Network Time Protocol) and configure clock skew tolerance (e.g. 180 seconds).

ErrorInvalid NameID or Missing Attribute

The SP expected an email address in the <NameID> element, but received an opaque ID or nothing. Check IdP attribute mapping and NameID policy format settings.

FAQ & Knowledge Base

Frequently Asked Questions About SAML 2.0 & SSO

Clear, developer-tested answers to the most common questions about SAML authentication, assertions, protocol comparisons, tracers, and security best practices.

SAML Basics, Meaning & Architecture

What is SAML and what does SAML stand for?

SAML stands for Security Assertion Markup Language. It is an open, XML-based standard defined by the OASIS consortium for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP).

The primary purpose of SAML is to enable cross-domain Single Sign-On (SSO). SAML 2.0, released in 2005, merged previous SAML 1.1 specifications, Shibboleth, and Liberty Alliance ID-FF into the definitive global enterprise standard powering corporate login across SaaS applications and cloud systems.

What is the difference between SSO and SAML?

The difference is simple: SSO (Single Sign-On) is an architectural concept and user experience model, whereas SAML is the technical protocol used to implement it:

  • SSO (Single Sign-On): Describes the experience of signing in once with a single set of corporate credentials and gaining seamless access to multiple independent applications (e.g., Slack, Salesforce, AWS) without having to re-authenticate for each one.
  • SAML (Security Assertion Markup Language): The XML-based communication standard that securely transmits cryptographic identity assertions from the central IdP to the application.

In short: SSO is the goal; SAML is the standard protocol that enables it.

What is SAML authentication and how does it work?

SAML authentication verifies a user's identity without requiring the destination application to ever handle, know, or store their password. It works through a pre-configured trust relationship between a Service Provider (SP) and an Identity Provider (IdP):

  1. AuthnRequest: When a user accesses an app, the SP redirects their browser to the IdP with a deflated, URL-encoded <samlp:AuthnRequest>.
  2. Authentication: The IdP authenticates the user via password, MFA, passkeys, or an existing session.
  3. SAML Response: The IdP constructs a cryptographically signed XML <samlp:Response> containing user assertions.
  4. HTTP-POST: The browser automatically submits the Base64-encoded assertion to the SP's Assertion Consumer Service (ACS) endpoint.
  5. Session Established: The SP verifies the signature against the IdP's public X.509 certificate and creates a local application session.
What is a SAML assertion and what does it contain?

A SAML assertion is a signed XML document issued by an Identity Provider that asserts verifiable facts about an authenticated user. It contains three core sections:

  • Subject (<saml:Subject>): Identifies the user, typically via a NameID containing their corporate email or unique directory ID.
  • Conditions (<saml:Conditions>): Defines validity constraints, including NotBefore and NotOnOrAfter timestamps (normally 5 minutes) and an AudienceRestriction to prevent token reuse across other apps.
  • AttributeStatement (<saml:AttributeStatement>): Key-value profile claims like email, firstName, lastName, and groups used for Just-In-Time (JIT) provisioning.

Protocol Comparisons: SAML vs OIDC, OAuth & SCIM

SAML vs OIDC (OpenID Connect): What is the difference?

Both SAML 2.0 and OIDC (OpenID Connect) are federated identity protocols designed for Single Sign-On, but they differ fundamentally in architecture:

  • Payload Format: SAML uses verbose XML documents cryptographically signed with XMLDSig. OIDC is built on OAuth 2.0 and uses lightweight JSON Web Tokens (JWTs).
  • Target Ecosystem: SAML is the undisputed standard for enterprise B2B SaaS, corporate intranets, and government portals. OIDC is the dominant standard for modern web apps (SPAs), native mobile apps, and developer-facing consumer services.
  • Implementation: SAML requires specialized XML parsing and schema validation libraries. OIDC JWTs are natively parsed and validated in modern JavaScript and all server runtimes with minimal overhead.
SAML vs OAuth 2.0: How do they compare?

The fundamental difference is that SAML is for authentication, while OAuth 2.0 is for authorization:

  • SAML (Authentication): Proves identity (*"Who is this user?"*). It passes an assertion proving the user logged in successfully.
  • OAuth 2.0 (Authorization): Grants scoped API permissions (*"What can this application do on behalf of the user?"*). It issues Access Tokens allowing one service to access data in another service without exposing user credentials.

Enterprises frequently pair them together: employees log in to an internal portal using SAML SSO, and the portal uses OAuth 2.0 tokens to call downstream microservices and APIs.

SCIM vs SAML: What is the difference between provisioning and authentication?

SAML handles authentication (verifying user identity at login), while SCIM (System for Cross-domain Identity Management) handles automated user provisioning and deprovisioning:

  • With SAML alone, an application only learns about a user when they log in for the first time (Just-In-Time or JIT provisioning). When an employee is fired or departs, SAML *cannot* notify applications to deactivate their account.
  • SCIM solves this by synchronizing user accounts continuously via REST APIs. When an IT admin deactivates a user in Okta or Microsoft Entra ID, SCIM instantly disables their account across Slack, GitHub, Salesforce, and all connected SaaS apps simultaneously.

Diagnostics, Tracing & Cybersecurity

What is a SAML tracer and how do you trace SAML in Chrome?

A SAML tracer is a diagnostic tool or browser extension (such as the popular SAML-tracer extension for Google Chrome and Firefox) that logs HTTP traffic in real time and highlights SAML and WS-Federation authentication exchanges.

To trace SAML in Chrome:

  1. Open Chrome DevTools (F12), navigate to the Network tab, and enable Preserve log.
  2. Initiate the Single Sign-On flow in your browser.
  3. Filter requests by SAMLRequest (HTTP GET redirect) or SAMLResponse (HTTP POST payload to /saml/acs).
  4. Copy the raw parameter and paste it into SAMLDecoder.com to immediately inflate, format XML, inspect claims, and check X.509 certificates.
What is SAML in cybersecurity and what are common SAML vulnerabilities?

In cybersecurity, SAML serves as the primary authentication gateway for enterprise environments. Because validating a SAML token grants immediate access to privileged systems, flaws in SAML parsers represent high-severity security vulnerabilities:

  • XML Signature Wrapping (XSW): Attackers modify the XML DOM tree by inserting an untrusted assertion while preserving the original signed assertion, causing vulnerable parsers to verify the legitimate signature but execute the attacker's forged claims.
  • Golden SAML Attacks: If an attacker steals the private token-signing key from an Identity Provider (e.g. Active Directory Federation Services), they can forge arbitrary SAML assertions for any user, bypassing MFA entirely.
  • Replay Attacks & Excessive Clock Skew: Failing to validate strict NotBefore and NotOnOrAfter timestamps allows attackers to capture and replay assertions.
  • XML External Entity (XXE) Injection: Parsers that do not disable external DTDs can be exploited to disclose server files or launch SSRF attacks.
What is a SAML decoder and how do you decode SAML responses safely?

A SAML decoder reverses the multi-step encoding applied to SAML messages during network transit (URL-decoding query strings, inflating RFC 1951 raw Deflate compression streams, and Base64 decoding into indented XML).

Zero-Transmission Privacy Guarantee: Legacy tools (such as SAMLTool.com) transmit your production authentication tokens to external PHP servers, creating severe compliance and security violations (GDPR, SOC 2, HIPAA). SAMLDecoder.com performs 100% of decoding, XML formatting, and cryptographic certificate fingerprinting locally in your browser using the native WebCrypto API. No data ever leaves your computer.