Why does encoded text take more bytes than the original?

Your text can get bigger without gaining any information. Encoding needs extra room to spell the same data as text—here's why, and how to check whether the result fits.

Why does encoding make text bigger?

Encoding writes your data with a restricted alphabet so it can travel through places that expect text. Think of writing a number as ‘8’ or ‘eight’: the value stays the same, and the longer spelling takes more room. Your data hasn't gained anything; you've changed how it's written.

An input byte holds eight bits, the tiny on-or-off pieces of data. A Base64 character carries six, so the same bits need more characters to hold them.

Illustration: cat becomes three UTF-8 bytes. The same 24 bits are regrouped from three eight-bit bytes into four six-bit Base64 characters, Y2F0. Each output character occupies one UTF-8 byte. Base16 uses two hex characters for each input byte.

Illustration: regrouping the same bits

Same bits, more letters: Base64 writes three input bytes as four output characters. How we measured

UTF-8 is the way text becomes bytes before encoding. Our Unicode guide explains how it counts letters and emoji. For more on why apps use a text spelling of data, see how Base64 works.

A character limit and a byte limit aren't the same thing: letters, accents and emoji can take different amounts of room in UTF-8. FluffyBench's Base encoder shows both counts beside Input.

  1. FluffyBench Input showing café 👋, with different character and byte counts.
    FluffyBench Input showing café 👋, with different character and byte counts.
    Step 1. The accent and emoji take extra UTF-8 bytes before encoding even starts.
    1. An accent and an emoji are part of the text.
    2. Compare the character count with the byte count.

After encoding to Base16, Base64 or Bitcoin Base58, every output character is ASCII and takes one UTF-8 byte. That makes the result's character count a byte count too.

How much bigger are Base16, Base64 and Base58?

For a long piece of text, Base16 doubles the bytes, Base64 adds about 33% and Base58 a little more. A short word like hello grows by a different share, because Base64 pads its last group.

hello · 5 bytes input

Scale resets for each sample: 10 bytes

Input
5 bytes
Base16
10 bytes
Base64
8 bytes
Bitcoin Base58
7 bytes

A longer text file · 32,768 bytes input

Scale resets for each sample: 65,536 bytes

Input
32,768 bytes
Base16
65,536 bytes
Base64
43,692 bytes
Bitcoin Base58
44,750 bytes
Each card compares one input with all three encodings; labels give exact bytes.

Base64 writes 4 characters for each group of up to 3 input bytes. A short final group ends with padding (=), which counts toward your limit too.

Illustration: hello splits into hel and lo. hel becomes aGVs; lo becomes bG8=. Five input bytes become eight Base64 characters, including the padding character.

Illustration: hello in Base64

A short final group still takes four output characters.

What should you check when there's a byte limit?

The receiving app's format rule comes first: a smaller encoding won't help if the app can't read it. Compare sizes when the app lets you choose.

Start with the receiving app's encoding rule. If one format is required, use it; if alternatives are permitted, compare the same input in the allowed formats. Check the chosen output against the byte limit. If it's too large, shorten the input or ask for another transfer method.

Format choice and size check

Count the value the destination actually limits, including any wrapper it requires.

Need to compare the size of encoded text?

Doing it in FluffyBench: check your encoded size

FluffyBench's Base encoder lets you check your own text against a destination's limit. Here's hello in Base64; short inputs update automatically.

  1. From Text and To Base64 in FluffyBench.
    From Text and To Base64 in FluffyBench.
    Step 1. Choose the representations your destination asks for.
    1. Choose From: Text.
    2. Choose To: Base64.
  2. Input tab with hello, 5 characters and 5 bytes, and the Result tab.
    Input tab with hello, 5 characters and 5 bytes, and the Result tab.
    Step 2. Paste your text in Input; a short input updates automatically. Open Result on a phone.
    1. Paste your text here.
    2. Read the input characters and UTF-8 bytes.
    3. Open the Result tab.
  3. Base64 output aGVsbG8= and its 8-character readout.
    Base64 output aGVsbG8= and its 8-character readout.
    Step 3. Check the result: 8 Base64 characters means 8 UTF-8 bytes. Compare that count with your limit.
    1. Read the encoded text: aGVsbG8=.
    2. 8 Base64 characters means 8 UTF-8 bytes.
  4. Copy and Download controls for the Base64 result.
    Copy and Download controls for the Base64 result.
    Step 4. Use Copy for your clipboard, or Download to save the encoded text as a text file.
    1. Copy puts the result on your clipboard.
    2. Download saves the encoded text as a text file.

To compare another allowed encoding, switch To while keeping hello in Input.

Three FluffyBench Result headers for hello: Base16 has 10 characters, Base64 has 8, and Bitcoin Base58 has 7.

Same hello input, three To choices

Check the format name as well as the count: each encoding uses a different alphabet.

Need to encode a local file? FluffyBench's File to Base64 and data URLs handles file input and can add the data URL wrapper when your destination asks for it.

Why can zero bytes stay the same size in Base58?

Bitcoin Base58 keeps each leading zero byte by writing a 1 for it. When every input byte is zero, that makes one output character per input byte.

zeros.txt: 32 zero bytes become 32 Base58 1 characters, or 32 bytes. Base16 uses 64 bytes and Base64 uses 44 bytes. Enlarged cells show the start of each row; ellipses stand for the remaining cells.

Leading zero bytes and their Base58 symbols

Base58's length depends on the byte values as well as the input length.
Search FluffyBench