JWT token
Estimate JWT size (characters ↔ bytes) for cookies, Authorization headers, and header limits. Size only — no decoding and no signature verification.
Results
Enter data and click Calculate.
Why JWT size matters
JWTs ride along on many requests via Authorization, cookies, or bodies. Larger tokens mean more bytes × RPS, cookie-limit risk (~4 KB), and possible proxy rejection.
This calculator estimates size from Base64URL characters or pre-encode bytes. It does not decode claims or judge security.
What contributes to token length
- Header — usually small (
alg,typ). - Payload — claims; where bloat usually appears.
- Signature — algorithm-dependent fixed overhead (HMAC vs RSA/ECDSA).
Three Base64URL segments joined by dots — token.length in DevTools is the on-the-wire character count.
Claims: when a token becomes a mini-database
- Long role/permission string lists in the payload.
- Full user profiles instead of
sub+ server-side lookup. - Nested objects and “just in case” duplicated data.
“Just add more claims” has a cost: every request carries that baggage. A short access token plus session/cache data is often healthier.
Cookies, headers, and infrastructure limits
- Browser cookies: practical ~4 KB per cookie — 3000+ JWT characters is a red flag.
- Total header size may be capped by CDN/proxy/load balancers.
- Mobile networks: repeated overhead on every API call.
Size ≠ security
A short token is not “more secure” and a long one is not “more secure” — that axis is signature, TTL, rotation, audience. This tool only helps you avoid transport limits and wasted bytes.
Size examples (rule of thumb)
Chars → bytes mode uses floor(n×3/4).
| Token characters | ≈ bytes | Intuition |
|---|---|---|
| ~200 | ~150 B | compact access token |
| ~800 | ~600 B | a few claims + roles |
| ~3000 | ~2250 B | near cookie limits |
| ~5000+ | — | consider opaque session / reference |
Measure precisely: copy the full token and use token.length.
FAQ — JWT size
Size and transport — not decoding.
- Does this decode JWTs?
- No. It estimates size from character or byte length. It does not verify signatures or claims.
- Characters or bytes?
- Token from DevTools → chars→bytes. If you know claim JSON bytes before Base64URL → bytes→chars.
- Why are large JWTs in cookies painful?
- ~4 KB limits, every request resends the cookie, proxies may reject oversized headers.
- Are fewer claims always better?
- For size, yes. Auth design (ID + lookup vs fat token) is a separate decision.
- Base64 vs Base64URL?
- JWTs use Base64URL; the 3→4 ratio is the same for sizing.
- How do I measure precisely?
- Copy all three dot-separated segments and use
token.lengthin JS. - Is RS256 always larger than HS256?
- RSA/ECDSA signatures can be longer; claim payload often dominates anyway.
- What instead of a fat JWT?
- Short access token + server session/store, or an opaque session id in an HttpOnly cookie.