Base64 Size Overhead Calculator

Work out how much larger data becomes once base64 encoded.

Overhead
Adjust the inputs

Your result updates live as you type.

Base64 turns every three bytes into four printable characters, so the encoded form is one third larger. A 48 kB file becomes 64,000 characters, an overhead of 33.33 per cent. That ratio is fixed by the encoding and cannot be improved.

Line breaks add a little more. MIME wraps at 76 characters and PEM at 64, costing one byte per line, which takes the same file to 64,842 characters under MIME wrapping. Padding contributes at most two characters, since the encoder rounds the input up to a multiple of three.

The reason to care is transport. Base64 exists so binary data can survive channels that only handle text — email bodies, JSON payloads, data URIs, certificates. The 33 per cent penalty is the price of that safety, and it is why large attachments are far heavier in transit than on disk.

The formula

encoded = ⌈bytes ÷ 3⌉ × 4, overhead ≈ 33.3%
bytes
Size of the original binary data
⌈ ÷ 3⌉ × 4
Three input bytes become four output characters
padding
"=" characters when the input is not a multiple of three
wrap
Line length, which adds one byte per line break

How it works, step by step

  1. Enter the size of the original data in kilobytes.
  2. Choose whether line wrapping is applied.
  3. The gauge shows the percentage overhead.
  4. Read the encoded size and padding in the results.

Worked examples

A 48 kB attachment

48,000 bytes encodes to 64,000 characters, 16,000 bytes larger — 33.33 per cent. With MIME wrapping at 76 characters it reaches 64,842 bytes.

Why tiny inputs look worse

Four bytes encode to 8 characters, an overhead of 100 per cent, because padding rounds up to the next group of three. The penalty settles towards 33.3 per cent as inputs grow past a few hundred bytes.

How to read your score

0–33.34UnwrappedThe theoretical minimum of one third.
33.34–36WrappedLine breaks add a little over the minimum.
36–45Small inputPadding is significant relative to the payload.
45–—Tiny inputOverhead dominates; encoding is barely worthwhile.

Frequently asked questions

Can I compress base64 to get the space back?

Compress before encoding, not after. Gzip on already-encoded text recovers some of the expansion but never all of it, whereas compressing the binary first and then encoding gives a genuinely smaller result.

Why 33 per cent and not 25?

Four output characters carry three input bytes, so output is 4/3 of input. The increase is a third of the original, which is a quarter of the result — the two ways of stating it are often confused.

Does base64url differ in size?

No. It swaps two characters for URL-safe ones and often drops padding. Dropping padding saves at most two characters.

Should images be inlined as data URIs?

Only small ones. A data URI cannot be cached independently, adds a third to the bytes and delays first paint if it sits in the stylesheet or the document head.

Is base64 encryption?

No, and treating it as such is a recurring security failure. It is a reversible encoding with no key. Anyone can decode it in one command.

Encoded size at different inputs

Base64 output with and without line wrapping
InputUnwrappedMIME 76PEM 64Overhead
1 kB1,3361,3531,35633.60%
10 kB13,33613,51113,54433.36%
48 kB64,00064,84265,00033.33%
100 kB133,336135,090135,41933.34%
1 MB1,333,3361,350,8791,354,16933.33%

Sizes are in bytes; wrapping adds one byte per line break.

Related calculators