SAML Decoder: Decode SAML Requests & Responses

What is SAML?

SAML 2.0 (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP), which authenticates the user, and a Service Provider (SP), the application the user wants to access. It predates OpenID Connect and remains common in enterprise SaaS and legacy SSO integrations. See the history and future of SAML for background, and SAML and OpenID Connect for how the two protocols compare.

HTTP-Redirect vs. HTTP-POST bindings

A "binding" is how a SAML message travels through the browser. The HTTP-Redirect binding DEFLATE-compresses the XML, then base64- and URL-encodes it into a query parameter. That's compact, but limited by URL length, so it's typically only used for requests. The HTTP-POST binding base64-encodes (no compression) the XML into a hidden form field that auto-submits via JavaScript, used for most responses, which tend to be larger. This tool auto-detects and handles both, plus a plain pasted redirect URL.

Structure of a SAML Response

A typical SAML Response contains:

• Status: whether the request succeeded (urn:oasis:names:tc:SAML:2.0:status:Success) or failed, and why.
• Assertion: the actual identity claims, including Subject/NameID, Conditions (validity window, audience), AuthnStatement (how/when the user authenticated), and AttributeStatement (user attributes like email, groups, roles).
• Signature: an XML-DSig signature over the Response and/or Assertion, proving the IdP issued it unmodified. This tool reports whether a signature element is present and which algorithm it names, but doesn't perform XML-DSig canonicalization or cryptographic verification. Use your SP/IdP's own validation or a library like Microsoft.IdentityModel or OpenSAML for that. An EncryptedAssertion, if present, is flagged but can't be decoded here, since that requires the Service Provider's private decryption key.

Common SAML errors

Audience mismatch: the assertion's AudienceRestriction names a different SP entity ID than the one validating it. Clock skew: the IdP and SP clocks disagree enough that NotBefore/NotOnOrAfter rejects an otherwise-valid assertion. Most libraries allow a few minutes of skew tolerance. NameID format mismatch: the SP expects a specific Format (e.g. emailAddress) that the IdP didn't send.

How do I capture a SAML message to decode?

Open your browser's devtools Network tab before signing in, then look for the POST request to the SP's assertion consumer service (ACS) URL or the redirect to the IdP's SSO endpoint, and copy the SAMLResponse/SAMLRequest value. Enable "Preserve log" first so the request survives the redirect back to the SP. For a refresher on which party sends which message, see the 9 components of SAML.

Encoding a Redirect-binding SAMLRequest in .NET

// Decoding a Redirect-binding SAMLRequest/SAMLResponse query parameter
byte[] compressed = Convert.FromBase64String(samlRequestParam);

using var input = new MemoryStream(compressed);
using var deflate = new DeflateStream(input, CompressionMode.Decompress);
using var output = new MemoryStream();
deflate.CopyTo(output);

string xml = Encoding.UTF8.GetString(output.ToArray());

For a complete setup guide, see SAML 2.0 support in IdentityServer and setting up SAML single sign-on with Duende IdentityServer .