Skip to content
Calcrivo

SAML Assertion Size Calculator

Estimate SAML assertion size with attributes, signature and certificate, then test it against POST and Redirect binding limits.

Inputs

attributes
bytes
values
bytes
%

Raw Assertion Size

7.83 KiB

Size on the Wire

10.44 KiB

Binding Transport Limit

64 KiB

Binding Limit Utilisation

16.3%

Utilisation of an 8 KB Header Buffer

130.5%

Assessment

Too large for a cookie or an 8 KB header buffer — keep it in a POST body

Step by step

  1. Values used

    Attributes in the assertion = 18 attributes; Average bytes per attribute = 90 bytes; Group or role values = 25 values; Average bytes per group value = 40 bytes; Assertion is XML-signed = Yes; Signing certificate embedded in KeyInfo = Yes; Binding = HTTP-POST — assertion in a form field; Size remaining after DEFLATE = 30 %

  2. SAML Assertion Size

    assertion = fixed XML skeleton + attributes × bytes each + group values × bytes each + signature + embedded certificate, then base64-encoded at 4/3.

  3. HTTP-Redirect binding size

    HTTP-Redirect binding = DEFLATE, then base64, then URL-encode (about 1.4×), against a practical 2048-byte URL budget.

  4. Raw Assertion Size

    = 8,020.00

  5. Size on the Wire

    = 10,694.00

  6. Binding Transport Limit

    = 65,536

  7. Binding Limit Utilisation

    = 16.3

  8. Utilisation of an 8 KB Header Buffer

    = 130.5

  9. Assessment

    = Too large for a cookie or an 8 KB header buffer — keep it in a POST body

How it works

A signed assertion carrying an embedded certificate is around 2.8 KB before a single attribute, which is why real assertions land in the 4–8 KB range the specification's implementers expect. Base64 then adds a third on top, and the Redirect binding compresses first but pays it back in URL encoding. Assertion size is the usual root cause of SAML logins that work for most staff and fail for anyone in many groups, because the response outgrows a URL, a cookie or the default 8 KB header buffer.

Formulas

SAML Assertion Size

assertion = fixed XML skeleton + attributes × bytes each + group values × bytes each + signature + embedded certificate, then base64-encoded at 4/3.

1400
Typical XML signature block, and again for a base64 X.509 certificate
2600
Issuer, Subject, Conditions, AuthnStatement and namespace boilerplate
4/3
base64 expansion applied before transport

HTTP-Redirect binding size

HTTP-Redirect binding = DEFLATE, then base64, then URL-encode (about 1.4×), against a practical 2048-byte URL budget.

2048
Conservative URL length limit still enforced by old proxies and browsers
DEFLATE
Raw deflate compresses verbose XML to roughly 30% of its original size

Frequently Asked Questions

How is SAML Assertion Size calculated?

assertion = fixed XML skeleton + attributes × bytes each + group values × bytes each + signature + embedded certificate, then base64-encoded at 4/3. A signed assertion carrying an embedded certificate is around 2.8 KB before a single attribute, which is why real assertions land in the 4–8 KB range the specification's implementers expect. Base64 then adds a third on top, and the Redirect binding compresses first but pays it back in URL encoding.

Why does SAML Assertion Size matter?

Assertion size is the usual root cause of SAML logins that work for most staff and fail for anyone in many groups, because the response outgrows a URL, a cookie or the default 8 KB header buffer.

What values do I need to enter?

This calculator takes 8 inputs: Attributes in the assertion, Average bytes per attribute, Group or role values, Average bytes per group value, Assertion is XML-signed, Signing certificate embedded in KeyInfo, Binding, Size remaining after DEFLATE. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why is HTTP-POST preferred over HTTP-Redirect for responses?

Because a response carries the signed assertion and rarely survives a URL. Even after DEFLATE and base64 it typically exceeds the 2 KB that old proxies and browsers reliably accept, so the specification expects responses over POST and reserves Redirect for the much smaller authentication request.

How do I shrink a SAML assertion?

Release only the attributes the service provider consumes, filter group values to those relevant to that application, reference the signing certificate by thumbprint instead of embedding it in KeyInfo, and sign the assertion rather than both the assertion and the response so you pay for one signature block instead of two.

You might also need