Why Email Attachments Are About a Third Bigger Than the Original File
An image that was 900KB comes out well over a megabyte after it's embedded as a data URI or sent as an email attachment, and the natural assumption is that something broke: a failed compression setting, a corrupted export, a mail client mangling the file. Nothing broke. Attach a file to an email and, somewhere in transit, it quietly grows by about a third. That's not inefficiency. It's the deliberate cost of a decades-old fix for a limitation email was never designed around.
The math behind the 33% overhead
Base64 re-represents 3 raw bytes of binary data using 4 ASCII characters. But each of those characters only carries 6 usable bits of information instead of a full 8. That mismatch, 4 characters doing the work of 3 bytes, is a fixed, reliable ratio: encoded output runs about 4/3 the size of the original data, a genuine ~33% size increase before even counting the extra line-break characters some formats require.
If that jump looks like a bug, it isn't one. Every Base64-encoded file grows by roughly the same fixed ratio, regardless of what's inside it: a photo, a PDF, a font file, all the same. The size increase is a property of the encoding itself, not a sign that anything about your specific file went wrong on the way out.
Why binary-to-text encoding exists at all
Early internet email (the SMTP protocol) was built around plain 7-bit ASCII text, not raw 8-bit binary. Sending unencoded binary data through that path was unreliable. Control characters and high-bit-set bytes could get mangled or silently stripped by intermediate mail relays along the way. Base64 sidesteps the whole problem by only ever using a fixed set of 64 characters that are guaranteed safe, printable ASCII.
Formalized as part of MIME in the early 1990s
Base64 encoding for email was formalized as part of the MIME standard (RFC 2045) in the early 1990s, giving email a standardized way to carry attachments, images, and other binary content safely through infrastructure that was never designed to handle it directly. That's the same underlying mechanism still running every time an email client shows you a file attachment today.
Where the same tradeoff shows up outside of email
The identical size penalty appears anywhere Base64 is used to embed binary data inside text-based formats. Most visibly, embedding an image directly into HTML or CSS as a "data URI" instead of linking to the original file. It saves an extra network request, but it does so by paying the same roughly 33% size tax as an email attachment, for exactly the same structural reason.
What to actually do about it
If the goal is confirming nothing is broken, check the ratio: encoded output should run close to 4/3 the size of the original, consistently, no matter what the file is. If it's dramatically more than that, something else is adding overhead, but the base 33% itself is never a bug. If the goal is keeping file size down, the fix isn't a different encoding, it's avoiding Base64 where you can: link to an image file instead of inlining it as a data URI, or share a link instead of a raw attachment for anything large. If the goal is just understanding what a tool is doing to your file before you send it, run it through an encoder yourself and see the size difference directly.
Encode or decode text as Base64 or URL-encoded with the Base64/URL encoder.