/tutorials/base64-and-file-size
Base64 and File Size: Why Encoded Data Is Always Bigger
The exact reason Base64 encoded data takes up more space than the original, and when that overhead is worth accepting.
4 min read
Run Base64 EncoderRelated tools
Where the extra size actually comes from
Base64 represents every three bytes of original data using four text characters. Since three bytes is twenty four bits and four characters at six bits each is also twenty four bits, no actual information is lost, but the encoded form is always roughly thirty three percent larger than the original, purely because text characters are a less space efficient way to represent the same bits than raw binary is.
A concrete example
A 300 kilobyte image file, once Base64 encoded, becomes roughly 400 kilobytes of text. Embed that same image as a data URI directly inside a webpage a hundred times across a site with no caching benefit, and the extra hundred kilobytes per instance adds up to a real, measurable difference in how much data every visitor downloads.
When the tradeoff is actually worth accepting
For very small files, a handful of kilobytes at most, such as an icon or a small inline font, avoiding an entire separate network request often outweighs the size increase, particularly on a connection where each additional request carries its own latency cost. The calculation flips for larger files: a full size image or a font family with several weights is almost always better served as a separate file that the browser can cache independently and reuse across pages, rather than being repeated as inline Base64 text every single time.
Why compression does not fully undo the overhead
Gzip and similar compression can shrink Base64 text somewhat, since it is fairly repetitive, but it does not recover the full size difference, because compressing already dense binary data yields little benefit while compressing its Base64 representation still leaves noticeably more bytes than compressing the original binary directly would have. Base64 overhead is a genuine cost, not something that disappears once a server enables compression.
Seeing the size difference yourself
Paste a longer piece of text into the Base64 Encoder and compare the character count of the input against the encoded output. The roughly one third increase holds consistently regardless of what the original content actually is, since it comes directly from how the encoding works rather than anything specific to a particular file type.
Related tutorials
