Base64 Size Calculator
Turn byte counts into base64 encoded size with overhead bytes and percent.
What it does
Base64 trades size for text safety at a fixed ratio: every 3 bytes become 4 characters. Three thousand bytes encode to 4,000 with 1,000 overhead, about a third larger.
The tool above takes input bytes. It returns encoded bytes, overhead bytes, and overhead percent, so data URLs, email attachments, and JSON blobs can be budgeted before encoding.
This math fits standard padded base64 with 4 char quanta. It does not fit unpadded URL variants that trim equals signs, nor line wrapped MIME with 76 char breaks.
Encoding standards frame the same ratio: 24 bit input groups as four 6 bit output chars with equals padding on short final groups. Developer guides restate the third larger rule with padding notes.
Budget encoded size, not input size, for quotas. Payload limits read the 4,000 figure, never the 3,000.
How to use
- Enter input bytes before encoding.
- Read encoded size first for quotas.
- Read overhead bytes for the tax line.
- Read overhead percent to feel the ratio.
- Compare against URL safe variants separately.
- Add line wrap overhead for MIME paths.
Formula
- bytes
- Binary input octets to encode.
- encoded
- Padded base64 output characters.
- overhead
- Extra bytes versus input.
Zero bytes encode to zero with zero percent. Short final groups pad to 4 chars. Unpadded variants trim equals signs outside this math.
Worked example
Example: 3,000 input bytes
Input bytes 3000.
- Groups: 3000 / 3 = 1000 full groups.
- Encoded: 1000 x 4 = 4,000 bytes.
- Overhead: 4000 - 3000 = 1,000 bytes.
- Percent: 1000 / 3000 x 100 = 33.3 %.
- Tool shows 4,000 bytes, 1,000 bytes, 33.3 %.
Reference table
| Input | Encoded | Overhead |
|---|---|---|
| 3 bytes | 4 bytes | 1 bytes |
| 3,000 bytes | 4,000 bytes | 1,000 bytes |
| 3,000,000 bytes | 4,000,000 bytes | 1,000,000 bytes |
Limits
- Padded standard only. URL safe trims differ.
- Ignores MIME line wrap bytes.
- Ignores data URL prefixes like data: headers.
- Tiny inputs show huge percents, like 300% at 1 byte.
Common mistakes
- Budgeting input bytes against encoded quotas.
- Forgetting padding on 1 and 2 byte tails.
- Reading 33% as exact for tiny inputs.
- Mixing unpadded URL sizes into standard math.
- Skipping data URL header bytes in totals.
Try it yourself
Quick checks. Answers sit tucked under each question.
0 bytes?
0 bytes, 0 bytes, 0.0 %.
1 byte?
4 bytes, 3 bytes, 300.0 %.
6 bytes?
8 bytes, 2 bytes, 33.3 %.
Questions
How much bigger is base64?
About a third. 3 bytes become 4 chars, so 3,000 grows to 4,000.
What is base64 padding?
Equals signs completing short final groups to 4 chars. One input byte gives 2 chars plus ==.
Why is 1 byte 300% overhead?
One byte still costs 4 chars. Small inputs amplify the ratio.
Does URL safe base64 differ?
Slightly. It swaps chars and often trims padding, changing exact bytes.
What about MIME line wraps?
They add CRLF bytes per 76 chars outside this core math.
When should I avoid base64?
Large binaries. Binary transfer beats text encoding by a third.