JWT Payload Byte Size
Predict the on-the-wire size of a signed JWT before it blows past your cookie or proxy header limits.
Your recent runs (stored only in your browser)
No calculations yet — results land here so you can compare runs.
The engineering
A JWT is three base64url segments joined by dots: header, claims payload, and signature. Base64url inflates every raw byte count by a factor of 4/3 (rounded up, no padding per RFC 7515), so a 180-byte claims object costs 240 bytes on the wire before the signature even shows up. This card takes your raw JSON sizes and the signing algorithm and predicts the full token, plus the complete Authorization header line with the 22-byte "Authorization: Bearer " prefix.
The signature choice matters more than people expect: HS256 and ES256 add ~43–86 encoded bytes, but RS256 with a 2048-bit key adds 342 — and 4096-bit RSA adds 683. Rules of thumb: everything grows ~33% through base64url; RFC 6265 only guarantees 4096 bytes per cookie, so a token stored in a cookie should stay well under that; and nginx defaults to an 8 KiB request-header buffer — one bloated token plus a few tracking cookies can trip a silent 400/431 that looks like a load-balancer ghost.
If the total surprises you, audit the claims: every custom claim key ships in full on every request. Ten characters of key name across a million requests a day is real bandwidth, and role/permission arrays are the usual offenders.
Where this math comes from
The base64 machinery is older than the web itself: John Linn specified it in RFC 989 (1987) so Privacy-Enhanced Mail could push binary ciphertext through 7-bit mail relays. Simon Josefsson's RFC 4648 (2006) added the URL-safe alphabet — swapping + and / for - and _ and dropping the padding — which is exactly the encoding JWTs use, and exactly why the ⌈4n/3⌉ formula on this card has no padding term.
The token itself came out of the identity wars of the early 2010s. Mike Jones at Microsoft, with John Bradley and Nat Sakimura, drafted JWT starting in 2010–2011 as a compact, HTTP-friendly alternative to XML-heavy SAML assertions, deliberately sized to fit in a query parameter or header. The IETF JOSE working group ground the drafts into standards, publishing JWS (RFC 7515) and JWT (RFC 7519) together in May 2015 — and OpenID Connect and OAuth 2.0 bearer flows made the three-dot-separated blob the default credential of the modern web.
- 1987John LinnRFC 989 defines base64 so Privacy-Enhanced Mail can survive 7-bit relays.
- 2006Simon JosefssonRFC 4648 standardizes the unpadded, URL-safe base64url variant JWTs rely on.
- 2011Mike Jones, John Bradley, Nat SakimuraFirst JWT internet-drafts propose a compact JSON alternative to SAML assertions.
- 2015IETF JOSE working groupRFC 7515 (JWS) and RFC 7519 (JWT) published, pinning the encoding rules this card computes.
See the full timeline of the math behind every calculator →
Runs entirely in your browser — nothing you enter leaves this page. Your recent runs are stored only on your device.