SAML Assertion Size Calculator
Estimate SAML assertion size with attributes, signature and certificate, then test it against POST and Redirect binding limits.
Inputs
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
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 %
SAML Assertion Size
assertion = fixed XML skeleton + attributes × bytes each + group values × bytes each + signature + embedded certificate, then base64-encoded at 4/3.
HTTP-Redirect binding size
HTTP-Redirect binding = DEFLATE, then base64, then URL-encode (about 1.4×), against a practical 2048-byte URL budget.
Raw Assertion Size
= 8,020.00
Size on the Wire
= 10,694.00
Binding Transport Limit
= 65,536
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
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
- JWT Payload Size CalculatorCommonly used together
- Federation Trust CalculatorCommonly used together
- OIDC Session CalculatorCommonly used together
- IAM Health Score CalculatorAlso in Identity & Access Management
- IAM Policy Size CalculatorAlso in Identity & Access Management
- Identity Lifecycle CalculatorAlso in Identity & Access Management