Example 1
- 200 characters
- chars-to-bytes
≈ 150 B
How many B from 200 characters? ≈ 150 B. A Base64 estimate, not a JWT decoder.
JWT token
Type characters or bytes. 200 characters give ≈ 150 B. 300 B in bytes-to-chars stays ≈ 300 B. 1024 characters give ≈ 768 B. A Base64 estimate, not a JWT decoder.
The integer part of (n×3/4) from characters, or ceil(n/3)×4 the other way. The result is the bytes line. Not a decoder. 4-on-3 overhead sits on Base64 size.
Results
Enter data and click Calculate.
How it works
JWT token in this calculator estimates bytes from a length. 200 characters give ≈ 150 B. 300 in bytes-to-chars stays ≈ 300 B, because the result is the bytes line. 1024 characters give ≈ 768 B. A Base64 estimate, not a JWT decoder.
Field jwt-chars is a number. Select jwt-base in the examples is chars-to-bytes, bytes-to-chars, then chars-to-bytes again. the integer part of 200×3/4 = 150. 300 B stays 300 on the bytes side. the integer part of 1024×3/4 = 768.
150 B is not a decoded payload. 300 B is not a signature check. 768 B does not know an Authorization header. You type the length. The calculator does not parse a JWT.
Base64 size next door counts ceil(n/3)×4. JSON size multiplies characters. Here 200 stays ≈ 150 B, the 3-on-4 overhead alone.
Type 200 and chars-to-bytes, then Calculate. The result is ≈ 150 B. Zero leaves 0 B. This is not a token decoder.
200 give ≈ 150 B. 300 B stays ≈ 300 B. 1024 give ≈ 768 B. Another mode at 200 changes the calculator; the result keeps bytes.
Formula
chars to bytes: floor(n×3/4). Bytes to chars: ceil(n/3)×4. The result is the B line. Not a JWT decoder.
How to use
- Type 200 and mode chars-to-bytes.
- Click Calculate. The result is ≈ 150 B.
- 300 in bytes-to-chars stays ≈ 300 B. 1024 give ≈ 768 B.
- A Base64 estimate, not a JWT decoder.
- 4-on-3 overhead sits on Base64 size.
200 characters = ≈ 150 B
A Base64 estimate, not a JWT decoder. 200 give ≈ 150 B. 1024 give ≈ 768 B.
- JWT
- A 3-on-4 estimate. 1024 give ≈ 768 B. Not a decoder.
- token
- A typed length. 300 B stays ≈ 300 B. Not a signature check.
- bytes
- The B line. 200 characters leave ≈ 150 B. Not a payload.
Examples
Example 2
- 300 B
- bytes-to-chars
≈ 300 B
What about 300 B in bytes-to-chars? ≈ 300 B. The result stays the bytes line.
Example 3
- 1024 characters
- chars-to-bytes
≈ 768 B
What about 1024 characters? ≈ 768 B.
Related calculators
Common questions
How many B from 200 characters?
≈ 150 B. That is the integer part of 200×3/4. A Base64 estimate, not a JWT decoder.
What about 300 B in bytes-to-chars?
≈ 300 B. The result is the bytes line.
What about 1024 characters?
≈ 768 B. That is the integer part of 1024×3/4.
Does the calculator decode a JWT?
No. Length only. No signature and no payload.
Why jwt-base?
chars-to-bytes goes to B. bytes-to-chars goes to characters. The result stays B.
Is 150 B a cookie after a write?
No. A 3-on-4 estimate. Not a file and not a odczyt nagłówka.
Does zero count?
Yes as 0 B. A blank field is a number error.
Where do I size Base64 from bytes?
On Base64 size. Here ≈ 150 B from 200 stays.
Is this a token validator?
No. No iss, exp, or signature. Length only.
Knowledge sources
The calculator counts bits, bytes or throughput from your numbers. Below are SI and bit definitions (NIST).
Page updated in 2026.
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 the integer part of (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.