Email Was Built for Text Only. Base64 Is the 1992 Workaround That Still Runs Email Attachments Today.

How Base64 Actually Works

Base64 represents arbitrary binary data using only 64 printable ASCII characters: the 26 uppercase letters A through Z, 26 lowercase letters a through z, the digits 0 through 9, and the symbols + and /. URL-safe variants (Base64url) replace + with - and / with _ to avoid conflicts in URLs and filenames.

The encoding algorithm works on groups of three bytes at a time. Three bytes is 24 bits. The encoding divides those 24 bits into four groups of 6 bits each. Each 6-bit value, which can range from 0 to 63, maps to one of the 64 characters in the Base64 alphabet. A 6-bit value of 0 maps to the letter A; 1 maps to B; 25 maps to Z; 26 maps to a; and so on through 63, which maps to /.

The expansion ratio of this process is fixed at 4/3: three bytes of input produce exactly four characters of output. A file that is 100 bytes becomes 133 or 136 Base64 characters (the number is rounded up to a multiple of 4). A 1 MB binary file encoded in Base64 becomes approximately 1.33 MB of text. For email attachments, this size increase is the cost of making binary data transmittable through text-only systems.

If the input length is not a multiple of three, the algorithm pads the last group with zero bytes and marks the padding in the output with one or two = signs. This is why Base64 strings frequently end with = or ==. The = signs are structural markers, not padding content; they tell the decoder how many real bytes the final group contains.

Where Base64 Appears Beyond Email

Borenstein and Freed designed Base64 for email, but the underlying problem it solves, getting binary data through text-only systems without corruption, appears in many contexts. Base64 became the standard solution wherever binary data needs to travel through a system that was built for text.

Data URIs in HTML and CSS embed images, fonts, and other binary content directly into the document as Base64-encoded strings. The src attribute of an img element can be set to a string beginning with data:image/png;base64 followed by the Base64 encoding of the image file, and the browser renders it without making a network request. This is useful for small, frequently used images where the overhead of a separate HTTP request exceeds the cost of embedding the data directly. SVG icons and small background images are common candidates.

HTTP Basic Authentication encodes the username and password as a Base64 string and sends it in the Authorization header of the HTTP request. The encoded string looks like a meaningless sequence of characters, but it is trivially decodable. Base64 is encoding, not encryption: no key is required to reverse it. Sending Basic Auth credentials over an unencrypted HTTP connection is functionally equivalent to sending the password in plain text. The encoding exists only to prevent the colon character in the username:password combination from interfering with HTTP header parsing, not to provide any security.

JSON Web Tokens (JWTs) use Base64url encoding for both the header section and the payload section. The payload contains claims about the user, such as their ID or permission level. Anyone who receives a JWT can decode the header and payload without any key. JWT security relies entirely on the cryptographic signature appended to the token, not on the encoding of the payload. Treating the payload as "hidden" because it is Base64-encoded is a common security misconception.

Conclusion

Base64 is not compression, not encryption, and not a hash. These distinctions matter in practice.

A compressed file uses an algorithm like gzip or Brotli to find redundant patterns and represent them more compactly. The output is smaller than the input. Base64 output is always larger than the input by one third.

An encrypted file is transformed using a key such that the output cannot be reversed without the key. Base64 output is trivially reversible by any decoder without a key.

A cryptographic hash is a one-way function: given a hash value, the original input cannot be recovered. Base64 is fully reversible. A Base64-encoded password is not a stored password; it is a password that anyone who sees the Base64 string can read in full.

The confusion arises partly because Base64 output looks like random characters to an untrained eye, similar to how encrypted or hashed data looks. The resemblance is superficial. A single online decoder retrieves the original from any Base64 string in under a second.

When Base64 appears in a web application, understanding what it is encoding is necessary for security analysis. A JWT payload encoded in Base64url may contain sensitive claims about a user's permissions. A data URI containing a Base64-encoded image is simply an image. A Basic Auth header containing a Base64-encoded credential is a cleartext password with extra formatting. The encoding is the same; the security implications depend entirely on what is being encoded and how the credential or data is protected at the transport layer.

When you need to inspect what is inside a Base64 string, or encode content for a system that requires Base64 input, a decoder and encoder that operates without transmitting your data to an external server handles the task immediately. ToolHQ's Base64 encoder and decoder converts both ways, works in the browser without any server requests, and handles text and binary input formats.

Frequently Asked Questions

Try These Free Tools