b2KIT

SAML Validator

Validate SAML XML documents against SAML 2.0 schema and check for common configuration errors.

Tested tool guide Tested browser tools Checked August 16, 2026

What SAML Validator does, with a checked example

SAML 2.0 exchanges live or die by XML details that ordinary XML tools ignore. This tool takes a pasted SAML document - typically an assertion, an AuthnResponse, or IdP/SP metadata - checks that it is well-formed, then validates it against the official SAML 2.0 schema, which pins down things generic XML leaves loose: Version is fixed to '2.0', ID and IssueInstant are required, timestamps must be proper dateTime values, and child elements must appear in a strict order. A second pass targets common configuration errors. The usual surprise: a document can pass everything here and still be rejected by the service provider, because schema validity says nothing about signatures, audiences, or expiry.

Worked example

A concrete input and expected output from the current implementation.

Input

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                ID="_example1" Version="1.1"
                IssueInstant="2026-08-16T12:00:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
</saml:Assertion>

Expected output

Invalid. Schema error: the Version attribute must be the fixed value '2.0' per the SAML 2.0 assertion schema; the document declares Version="1.1".

The SAML 2.0 assertion schema declares Version as required and fixed to the string '2.0', so any other value fails validation no matter how well formed the rest of the document is. This is also why SAML 1.x documents never pass a SAML 2.0 schema check.

How the result is produced

1

Parse and schema check

The document is first checked for well-formedness; one unclosed tag fails before any SAML rule runs. Then it is validated against the SAML 2.0 schema, which is stricter than generic XML: Version is required and fixed to the string '2.0', ID and IssueInstant are required, timestamps must be valid xsd:dateTime values such as 2026-08-16T12:00:00Z, and child elements must appear in the schema's declared order - Issuer, Signature, Subject, Conditions, Advice, then statements.

2

Configuration-error checks

Schema-legal is not the same as deployable. The second pass targets errors that pass the XSD but break real integrations: timestamps that are already past or mutually inconsistent, placeholder values in Issuer, Recipient, or Audience, and elements the exchange contract requires but the document omits. It cannot verify trust: signature validation needs the IdP's public signing certificate, and final acceptance is decided by the SP's configuration, not by any schema.

Good uses

  • You captured a live AuthnResponse from the IdP - network tab, IdP logs, or a saved fixture - and want to confirm the XML is structurally sound before debugging the SP side of a failed login.
  • You hand-edited a metadata file or test assertion (changed a NameID format, fixed an entityID, added an AttributeStatement) and want to confirm you did not break element order, date formatting, or required attributes.
  • Your SP returns a terse error such as 'malformed SAML response', and you want to rule structure in or out before comparing certificates, clocks, and endpoint configuration across the two parties.

Limits and checks

  • Passing here is not acceptance. The SP can still reject the document because the signature does not validate, the Audience does not match its entityID, the Recipient is not its ACS URL, or its clock considers the assertion expired. A clean report means the document is well-formed SAML 2.0, nothing more.
  • A version or namespace failure does not always mean a broken document: a SAML 1.1 assertion (Version="1.1", namespace urn:oasis:names:tc:SAML:1.0:assertion) fails the 2.0 schema by design, and that failure is expected, not a defect in the document. If your stack speaks SAML 1.x, this tool's answer is the wrong yardstick.
  • Nothing here compares the document's timestamps with the current clock or with the SP's expectations. An assertion that passed last week can be rejected today for expiry with the XML byte-for-byte unchanged, and it still validates cleanly. Pair a clean report with the SP's own error details before concluding the document is the problem.

Common questions

Why does my assertion fail validation even though the XML looks normal?

Two causes cover most cases. Element order is fixed by the schema - Issuer, Signature, Subject, Conditions, Advice, then statements - and hand-built or reformatted XML frequently reorders elements, which generic XML parsers allow. Second, Version must be exactly '2.0' and timestamps must be complete dateTime values like 2026-08-16T12:00:00Z; a bare date such as 2026-08-16 is a type error.

Can this tell me whether the IdP's signature is valid?

No. Schema validation does not perform cryptography. Verifying an XML signature requires the IdP's public signing certificate, normally published in its metadata, and signature processing is outside what a schema check does. Even a correctly signed assertion can be rejected if the SP does not trust the certificate or the audience does not match. Use this tool for structure, not for trust.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

Password Generator

Generate strong, random passwords with customizable length, character sets, and complexity requirements.

Password Strength Checker

Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.

Random String Generator

Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.

QR Code Generator

Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.

QR Code Reader

Scan and decode QR codes from uploaded images or your device camera to extract embedded data.

File Checksum Calculator

Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.