Example 1
- 100 B
- mode bytes
136 B
What Base64 size from 100 B in bytes mode? 136 B. A length estimate, not an encode.
Base64 size
Type bytes and a mode. 100 B become 136 B. 1024 B become 1368 B. 50 B become 68 B. A length estimate, not a file encode.
A length estimate, not an encode. JWT tokens live on JWT token size.
Results
Enter data and click Calculate.
How it works
Base64 size in this calculator estimates length from the bytes you type. 100 B become 136 B. 1024 B become 1368 B. 50 B become 68 B. In bytes mode the formula is ceil(n/3) × 4. The calculator does not encode a payload and does not paste a file.
Field b64-bytes is a number. Select b64-mode stays bytes in the examples. 100 / 3 is 34 groups, times 4 is 136. 1024 is 1368. 50 is 68. Encoded mode runs the other way and is not in these three cards.
136 B is not a file after btoa. 1368 B does not come from an encoder. 68 B is not a string from disk. You type the length. The calculator does not read MIME and does not add a data URI.
JWT token size next door estimates token characters. JSON size multiplies characters by bytes. Here 100 B stays 136 B, the 4-on-3 overhead alone.
Type 100, leave bytes mode, then Calculate. A comma is not needed, because the field is an integer. Zero bytes leave 0 B. This is not an encode in the browser.
100 B become 136 B. 1024 B become 1368 B. 50 B become 68 B. Another mode at 100 changes the calculator; the examples keep bytes.
Formula
in bytes mode: ceil(n/3) × 4. A length estimate, no payload encoding.
How to use
- Leave the mode on bytes.
- Type 100 in the value field.
- Click Calculate. The result is 136 B.
- 1024 B become 1368 B. 50 B become 68 B.
- A length estimate, not a payload encode.
100 B = 136 B
A length estimate in bytes mode. 100 B become 136 B. The calculator does not encode a payload.
- Base64
- The 4-on-3 overhead. 100 B leave 136 B. 1024 B leave 1368 B.
- bytes
- The b64-mode value in the examples. 50 B in bytes give 68 B.
- length
- The calculator result. 136 B is an estimate, not a file encode.
Examples
Example 2
- 1024 B
- mode bytes
1368 B
What about 1024 B in bytes mode? 1368 B.
Example 3
- 50 B
- mode bytes
68 B
What about 50 B in bytes mode? 68 B.
Related calculators
Common questions
What about 100 B in bytes mode?
136 B. ceil(100/3) × 4. A length estimate.
What about 1024 B?
1368 B. The same bytes mode.
What about 50 B?
68 B. A small block, a higher padding share.
Does the calculator encode a file?
No. No btoa and no pasted payload. Length only.
Why b64-mode?
bytes goes from bytes to Base64. encoded goes the other way. The examples keep bytes.
Is 136 B characters or stored bytes?
The calculator shows 136 B as the encoded length. Not a file after a disk write.
Does zero count?
Yes as 0 B. A blank field is a number error.
Where do I size a JWT?
On JWT token size. Here the 4-on-3 overhead stays.
Is this compression?
No. Base64 grows. Gzip is a separate step, not on this calculator.
Knowledge sources
The calculator counts bits, bytes or throughput from your numbers. Below are SI and bit definitions (NIST).
Page updated in 2026.
What Base64 size means in practice
Base64 turns bytes into ASCII-safe text for JSON, XML, email, and data-URIs. It is transport encoding, not compression — the encoded string is usually larger than the original bytes.
This calculator answers: “how many characters will N bytes become?” and “how many bytes sit behind a string of length M?” (the second mode is a lower bound without padding knowledge).
Why Base64 makes data larger
- Every 3 bytes (24 bits) map to 4 characters of 6 bits → a fixed 4:3 ratio.
- Lengths not divisible by 3 get
=padding so the string length is a multiple of 4. - In APIs the Base64 value is JSON text — you pay encoding overhead before any gzip on the whole body.
Larger blocks typically grow by about +33%. Tiny payloads look worse percentage-wise because of padding (e.g. 1 B → 4 chars).
Quick table: bytes → Base64
Canonical 4:3 pattern — enter the left column in binary-size mode.
| Raw bytes | Base64 chars | Overhead | Note |
|---|---|---|---|
| 3 | 4 | +33% | exact one triplet |
| 1 | 4 | +300% | padding dominates |
| 1024 (1 KiB) | 1368 | +33.6% | typical blob |
| 204800 (200 KB) | 273068 | +33.3% | image in JSON |
The calculator uses ceil(n/3)×4 — no MIME line wrapping.
Padding and how to read the modes
- Bytes → Base64 — exact string size (padding count in the note).
- Base64 length → bytes —
the integer part of (len×3/4); lower bound without padding. - Base64URL (JWTs) uses another alphabet but the same 4:3 ratio — use the JWT size tool for tokens.
When Base64 overhead actually matters
- JSON fields with inline binaries (
content,file, attachments). - MIME attachments, webhooks with large blobs, API gateway body limits.
- CSS/HTML data-URIs (plus the
data:…;base64,prefix) — prefer file URLs for big assets. - Logs and queues that index text: +⅓ length burns retention fast.
Numeric examples
- 3 B → 4 characters — the classic minimum block.
- 1024 B → 1368 characters (+33.6%).
- A 200 KB image in JSON → ~267 KB of Base64 text before gzip.
- A 16 B token → 24 chars: high percentage, small absolute size — judge against your body limit.