Tech Help
Why Does Base64 Make Files Bigger?
Base64 usually makes binary data about one-third larger. See the 3-byte to 4-character structure, padding, Data URL overhead, and when the extra size is worth it.
Base64 usually makes binary data about one-third larger because it represents every 3 bytes of binary data using 4 printable Base64 characters.
If the input length is not an exact multiple of 3, standard padded Base64 may add = characters. The encoded length is 4 × ceil(n / 3), where n is the original byte length.
“About 33%” describes large inputs. Tiny inputs can look like a much bigger percentage because of padding. Base64 is not compression. For encoding versus encryption, see [Base64 Is Not Encryption: What It Actually Does](/en/story/base64-is-not-encryption).
This article explains why Base64 output is larger than the original bytes. It is not a security guide. If you need encoding versus encryption, use Base64 Is Not Encryption: What It Actually Does.
Why Does Base64 Need More Space?
3 bytes are 24 bits. Base64 splits those 24 bits into 4 groups of 6 bits. Each group maps to one Base64 character, so 3 input bytes become 4 output characters. Stored as 1 byte per ASCII character, that is 4 / 3 ≈ 1.333 — about a 33.3% increase.
- 3 bytes (24 bits)
- Split into 4 groups of 6 bits
- Each group → one Base64 character
- 4 characters (often 4 bytes of text)
A Simple, Checkable Example
These encodings match standard padded Base64.
Man
Man
Base64
TWFu
Man is 3 UTF-8/ASCII bytes. TWFu is 4 characters: 3 → 4.
Hello
Hello
Base64
SGVsbG8=
Hello is 5 bytes. SGVsbG8= is 8 characters, including one =. On small data, padding makes the percentage look larger than 33%.
How Do You Calculate Base64 Size?
For standard padded Base64, encodedLength = 4 × ceil(originalBytes / 3).
| Original bytes | Base64 characters |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1 or 2 bytes still produce 4 characters. Use the formula, not a fixed 33%.
What Does the “=” Padding Mean?
The = mark shows that the last 3-byte block was not full. 1 input byte uses two = characters; 2 bytes use one; 3 bytes use none. Padding is not encryption or a security feature.
Does Base64URL Use Less Space?
Base64URL changes + to - and / to _, and Base64 Encode & Decode omits trailing = on encode. That can shorten the string by those = characters. The 3-byte → 4-character structure stays the same, so Base64URL is not a more space-efficient binary format.
Why Can Tiny Inputs Grow by More Than 33%?
1 byte → 4 characters is a 300% increase in length. 2 bytes → 4 is 100%. 3 bytes → 4 is about 33.3%. As n grows, padding matters less and the overhead approaches about 33%. Base64 is not always exactly 33% larger.
Why Is a Base64 Data URL Even Larger?
A Data URL adds a prefix such as data:image/png;base64, before the payload. On a tiny file that prefix can dominate the percentage. Base64 Encode & Decode can emit raw Base64 or a Data URL; Data URL output uses the standard alphabet.
Base64 vs Binary: Which Is Smaller?
Raw binary is more space-efficient for transport and storage. Base64 is larger, but text-safe in JSON, email, and other text-only paths. It is binary-to-text encoding, not compression.
Does Base64 Compress Files?
No. Base64 is not a compression format. The encoded text is usually larger than the original bytes. If you later apply gzip or Brotli to that text, some redundancy may shrink—results depend on the data and the compressor. gzip does not completely remove Base64 overhead.
What Happens If Base64 Is Gzipped?
HTTP compression can reduce some repeated patterns in Base64 text. JPEG, PNG, or ZIP often compress poorly even as raw bytes, and Base64-then-gzip is still case-dependent. There is no universal extra-percentage after gzip.
Should You Store Files as Base64?
Base64 can fit binary into a JSON field, a small inline asset, a text-only API, copy/paste, or a Data URL. For large files, storage, memory, and payload size all grow. That is not “never use Base64 for files.”
Why Is Base64 Common in JSON APIs?
JSON has no native raw-binary type, so APIs often put bytes in a Base64 string. For large files, multipart/form-data, object storage, or a direct binary upload can fit better. Neither choice is always best.
Why Is Base64 Used in Email?
MIME can use Base64 so a binary attachment travels as text-safe characters. The same size overhead still applies. This is a transport representation, not a smaller file.
When Is the Extra Size Worth It?
The extra size can be worth it when binary must sit inside text, the payload is small, an API requires Base64, or you need a Data URL. For large media, prefer raw binary when the system allows it.
When Should You Avoid Base64?
Skip it for large files, tight bandwidth, frequent transfers, or when a binary path already exists—situational, not “Base64 is bad practice.”
Padded Base64 Lengths You Can Check
Original byte counts and standard padded Base64 character counts:
| Original bytes | Base64 characters |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
All rows follow 4 × ceil(n / 3). These are Base64 character counts.
Example: How Large Will a 1,000-Byte File Become?
4 × ceil(1000 / 3). ceil(333.333…) = 334, and 4 × 334 = 1336. So 1,000 bytes become 1,336 Base64 characters. Stored as UTF-8/ASCII, each character is typically 1 byte—do not treat 1,336 as an exact in-memory byte count.
Can Base64 Use More Memory Than the File Size Suggests?
Some runtimes store strings with more than 1 byte per character, and encode/decode can keep a buffer and a string together. Memory use is not exactly the character length.
A Simple Size Decision Guide
If the system accepts raw binary, prefer it for size. If only text is allowed, Base64 may fit. For a large payload, check for a binary upload path. For URL-safe text, consider Base64URL—the 3-to-4 expansion remains.
- Need to send binary data
- Raw binary allowed? Prefer binary for size
- Text-only field? Base64 may be appropriate
- Large payload? Check for a binary upload path
- Need URL-safe text? Consider Base64URL
- Expect about 33% more text on large inputs
Base64 is not designed to make data smaller. It makes binary easier to represent inside text-based systems, and the cost is extra size.
Encode or Decode Base64 in Your Browser
NEXNARA Base64 Encode & Decode encodes and decodes text, and it can turn a file into Base64 or a Data URL and turn Base64 back into a file.
Text uses UTF-8 bytes, then Base64—not ASCII-only. Choose Standard or Base64URL. File output can be raw Base64 or a Data URL (standard alphabet). Invalid input is rejected. Non-UTF-8 bytes need To file, not text decode.
Files over 10 MB may slow the tab (warning). Files over 32 MB are blocked.
Encoding and decoding happen in your browser. The file is not sent to a NEXNARA server for this tool. Ads and other site features still use the network.
Paste text or a file in Base64 Encode & Decode and compare original bytes with the encoded length.
FAQ
Why does Base64 increase file size?
It maps 3 bytes (24 bits) to 4 characters (4 × 6 bits). Stored as text, that is about one-third more for large inputs.
Is Base64 always 33% larger?
No. Large inputs approach about 33.3%. Tiny inputs can grow more because of padding. Use 4 × ceil(n / 3).
How much larger is Base64 than binary?
Standard padded length is 4 × ceil(n / 3) characters. A Data URL prefix adds more.
Does Base64 compression reduce file size?
Base64 does not compress. Gzip or Brotli on the encoded text may shrink some of it; they do not erase the overhead in every case.
Does Base64URL use less space?
It can drop = padding, so the string may be 0–2 characters shorter. The 3-to-4 encoding structure is the same.
Should I use Base64 for large files?
Only if you need text. For large or frequent transfers, a binary path is often smaller. Base64 is not always wrong for APIs.