What Is Base64 Encoding and When Should You Use It?

Why Base64 Exists

Many communication protocols — email (SMTP), HTTP headers, HTML attributes — were originally designed to handle only printable ASCII text. Sending binary data (images, audio files, executable code) through these channels was problematic: certain byte values have special meaning as control characters, and some systems would corrupt or truncate binary content.

Base64 solves this by converting any binary data into a sequence of 64 printable ASCII characters. The result can be safely transmitted through any text-based protocol without modification or corruption. RFC 2045, which defined the MIME email standard in 1996, formalized Base64 as the standard encoding for binary email attachments.

How Base64 Encoding Works

The encoding process converts binary data in groups of three bytes (24 bits) into four Base64 characters (6 bits each):

1. Take 3 bytes of input (24 bits)
2. Split into four 6-bit groups
3. Map each 6-bit value (0–63) to a character in the Base64 alphabet
4. Output 4 characters

The Base64 alphabet is: A–Z (values 0–25), a–z (26–51), 0–9 (52–61), + (62), and / (63). This gives exactly 64 characters — hence the name.

Padding: When the input length is not divisible by three, the output is padded with one or two = characters to make the length a multiple of four. Padding tells the decoder how many "real" bytes are in the last group.

Size Overhead

Because every 3 bytes of input become 4 characters of output, Base64 encoding increases data size by approximately 33%. A 1 MB image encoded as Base64 becomes roughly 1.37 MB of text. This overhead is the main reason Base64 is avoided when binary transmission is possible — modern protocols like HTTP/2 handle binary natively, making Base64 unnecessary for most web transfers.

URL-Safe Base64

The standard Base64 alphabet includes + and /, both of which have special meaning in URLs. A standard Base64 string embedded in a query parameter would be misinterpreted: + would be decoded as a space, and / would be read as a path separator.

The URL-safe variant (defined in RFC 4648) substitutes - for + and _ for /. Padding characters (=) are often omitted as well, since they can cause issues in some URL contexts. This variant is used in JSON Web Tokens (JWT), where the three parts of the token are separated by dots and must not contain URL-reserved characters.

Where Base64 Is Used

• Data URIs: Embedding images directly in HTML or CSS — src="data:image/png;base64,iVBORw0..." — avoids a separate HTTP request at the cost of 33% size overhead
• JSON Web Tokens (JWT): The header and payload are Base64url-encoded JSON objects
• HTTP Basic Authentication: Credentials are sent as Authorization: Basic dXNlcjpwYXNz (Base64 of "user:pass")
• Email attachments: Binary files encoded for safe transmission through SMTP servers
• SSH public keys: The key data after the algorithm identifier is Base64-encoded
• Cryptographic keys and certificates: PEM format wraps DER-encoded binary in Base64 with header/footer lines

What Base64 Is Not

Base64 is not encryption. It is a reversible encoding with no key or secret — anyone can decode a Base64 string instantly. Encoding credentials or sensitive data in Base64 and treating it as secure is a common and dangerous mistake.

Base64 is also not compression. It makes data larger, not smaller. For actual compression, use gzip, Brotli, or similar algorithms. Some systems combine compression and Base64: compress the data first (to make it smaller), then Base64-encode the compressed result (to make it text-safe). The net result is often close to the original binary size while being text-transmittable.