Base64 size
Measure Base64 overhead: how large a string becomes after encoding, or how many raw bytes sit behind a Base64 length. Encoding — not compression. Results after Calculate.
Results
Enter data and click Calculate.
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 —
floor(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.
FAQ — Base64 overhead
Questions about encoding overhead, padding, and payload limits.
- What is the typical Base64 size increase?
- About +33% for larger blocks (4 chars per 3 bytes). Tiny inputs can show a higher percentage because of padding.
- Does Base64 compress data?
- No. Gzip/Brotli is a separate HTTP-body step — do not confuse it with Base64.
- What are the “=” characters for?
- Padding to a multiple of 4 characters when byte length is not divisible by 3. Bytes→Base64 mode shows the count.
- Why is length→bytes an estimate?
- Without padding, the lower bound is floor(len×3/4). Prefer binary→Base64 when you know the raw size.
- Do data-URIs also grow by ~33%?
- Yes versus file bytes, plus the
data:…;base64,prefix. Serve large assets as files. - Base64 vs Base64URL in JWTs?
- Same 4:3 ratio; different alphabet/padding. Use the JWT size calculator for token planning.
- Does gzip “undo” Base64 overhead?
- It can shrink transfer of the whole body, but gateways often count uncompressed bytes — you still carry longer JSON text.
- Is 1 B → 4 chars always +300%?
- Percentage-wise yes for 1 byte. At 1 KiB overhead returns to ~33%. Watch absolute bytes, not only percentages.