The Base64 Inflation

Executive Summary

Base64 is everywhere: every JWT token you issue, every data URI in your HTML, every API key your service hands out. And it always costs more than the textbook 33%. To quantify the real tax, we measured base64 inflation across the payloads that actually appear in production:

• A 10-byte secret inflates 60% — not 33%. The padding penalty dominates tiny inputs, and JWT headers, signature keys, and API keys are exactly this size class.
• A 32-byte JWT signature key inflates 37.5%. Your token's raw components total 177 bytes but the token string is 239 characters — 35% larger than the data it carries.
• A 200 KB screenshot becomes a 267 KB data URI inlined into your HTML — bloating every page that embeds it, un-cacheable and un-shareable.
• The compression trap: gzipping a base64-encoded payload is 22% worse than gzipping the raw bytes. "Compress after encoding" is a real, measurable mistake.

This briefing walks through the three base64 taxes, the data behind each, and a decision framework that tells you exactly when data URIs pay off and when they silently bloat your pages. Every number is reproducible — the benchmark methodology is in the final section, and the Base64 Encoder and Base64 Inflation Calculator tools at jslet will let you measure your own payloads.

Tax 1: The Small-Payload Penalty — 33% Is the Floor, Not the Rule

The textbook claim is that base64 expands data by 33%: every 3 bytes of binary become 4 ASCII characters (each character carries 6 bits, so 4 × 6 = 24 bits = 3 bytes). But that 33% is the asymptotic ratio for large inputs. Small payloads pay more, because base64 pads the final group to a multiple of 3 bytes with = characters, and that padding is pure overhead that cannot be avoided. Our measurements across real payload sizes:

Read the top rows again: the payloads where base64 overhead matters most — cryptographic keys, JWT components, API tokens — are exactly the ones that pay the most inflation. A 10-byte secret pays double the textbook rate. This is not a rounding detail; it directly affects token size, storage footprint, and transmission cost for the most sensitive, most repeated data in your system.

The fix is not to avoid base64 (it is required for text-safe channels) but to know the real number for your payload size. The Base64 Inflation Calculator computes the exact overhead for any byte count, including the padding penalty — so you stop planning with the 33% approximation and start planning with the true cost.

Tax 2: The Compression Trap — Gzip After Base64 Is 22% Worse

Here is the mistake that costs real bandwidth: someone base64-encodes a payload, then gzips it to "save space." The math quietly fails. We measured it on a realistic 104 KB JSON payload:

The result: compressing after base64 encoding produces a file 22% larger than compressing the raw bytes. The reason is structural — base64's 64-character alphabet is highly redundant from a compressor's perspective, but the 4/3 expansion happens before compression and cannot be recovered. The compressor sees 139 KB of text instead of 104 KB of binary; it does a good job on the text, but it can never undo the 33% it never got to see.

The correct pipeline is the reverse: compress first, then encode. Or better — if you control the HTTP channel (and you almost always do), skip base64 entirely. Send raw binary with the proper Content-Type header, and let gzip/Brotli at the transport layer do its job on the original bytes. HTTP was designed for binary; base64 is a workaround for text-only channels like email and URL query strings.

Tax 3: The Silent JWT and Data URI Overhead

Two of the most common base64 uses in production are also the least questioned. Let's measure both.

JWT: a typical token with header, payload, and signature has raw components totaling 177 bytes. Encoded as URL-safe base64 and joined with dots, the token string is 239 characters — 35% larger than the data it carries, and that is before considering that the payload itself is often already-text JSON (which base64 then re-encodes inefficiently). At scale, the overhead compounds: a service issuing 10 million tokens a day with ~60 bytes of average encoding overhead per token moves ~600 MB/day of pure encoding tax across storage and transmission. The overhead is justified (URL-safe tokens need it), but it should be a conscious decision, not an accident — keep claims minimal, avoid duplicating large fields, and watch token size if it shows up in your network metrics.

Data URIs: inlining an image as data:image/png;base64,... embeds it directly in HTML or CSS. The measured impact:

The hidden cost of data URIs is not just the 33% — it is that inlined assets cannot be cached, shared across pages, or preloaded. A favicon at 1.4 KB is fine; a 267 KB screenshot inlined into every page is a monthly bandwidth bill written directly into your HTML. The break-even analysis is in the decision framework below.

The Decision Framework: When Is Base64 Worth It?

The 2026 answer in one sentence: base64 is a transport workaround, not a storage or compression strategy — pay its tax only where text-safety is mandatory, and measure it where it matters (JWTs, data URIs, API keys), because the real rate is often 35-60%, not 33%.

How To Audit Your Own Base64 Tax

1. Find your base64 inventory. Grep your codebase for base64, btoa, Buffer.from(...).toString('base64'), and data:image/ URIs. You will be surprised how many there are.

2. Measure token sizes. If you issue JWTs, log token byte length in your API metrics. A token that crept from 300 to 600 chars over the years is a bandwidth tax nobody noticed.

3. Audit data URIs. List every data: URI in your HTML and CSS. Anything over 50 KB is a strong candidate for extraction to a separate cached file. Use the Base64 Image Encoder to see the exact URI size before deciding.

4. Check your compression pipeline. If anything in your build does base64-then-gzip, flip the order. The 22% difference we measured is free bandwidth once you fix the pipeline.

5. Set a policy. Document: base64 only for text-safe channels, data URIs only under 5 KB, compression always before encoding. A one-page policy prevents the tax from silently re-accruing.

Frequently Asked Questions

Methodology & Disclosure

Measurements performed with Python 3.12 stdlib (base64, zlib): random binary of specified sizes encoded with standard base64, length compared to input. JSON payload benchmark: 2,000-item object array (104,587 bytes), compressed with zlib level 9. JWT measurement: realistic header + payload + 32-byte HMAC-SHA256 signature, URL-safe base64, total token length compared to raw component bytes. Data URI measurement: random binary of 1 KB / 8 KB / 200 KB plus the 22-character data:image/png;base64, prefix. All results reproducible — the benchmark script is available on request.

Disclosure: jslet is an independent research project. We are not sponsored by any encoding library, token vendor, or CDN.

References & Further Reading

1. RFC 4648 (2006). "The Base16, Base32, and Base64 Data Encodings." The authoritative spec for base64 including padding rules. datatracker.ietf.org
2. RFC 7515 (2015). "JSON Web Signature (JWS)." Base64url encoding in JWT/JWS. datatracker.ietf.org
3. MDN Web Docs (2026). "Data URLs." When to use data URIs and their performance implications. developer.mozilla.org
4. web.dev (2026). "Optimize your images" and "Reduce payloads" — data URI and image delivery guidance. web.dev/learn/images

Cite as: jslet Research, 2026 — “The Base64 Inflation.” jslet.com. All benchmark data is original and reproducible with the linked tools.

📜 Copyright & Attribution

📡 Enjoyed this? Your JWT is 35% larger than the data it carries, and nobody on your team measured it. RSS covers one encoding/performance reality check per week. RSS Feed → | More options →