Base64 Encoding Explained — What It Is and When to Use It

Base64 is an encoding scheme that converts binary data into a text representation using 64 ASCII characters: A-Z, a-z, 0-9, +, and /. It's not encryption — it doesn't hide data. It's a way to represent binary data (images, files, arbitrary bytes) as plain text that can safely travel through text-based systems.

The name "Base64" comes from the 64-character alphabet used. Three bytes of binary data (24 bits) are split into four 6-bit groups, and each group is mapped to one of the 64 characters. This means Base64-encoded data is always about 33% larger than the original binary data.

Base64 was originally designed for email (MIME), which was text-only and couldn't handle binary attachments directly. Today it's used far beyond email — in APIs, HTML, CSS, and anywhere binary data needs to be embedded in text formats.

The encoding process is straightforward once you understand the bit manipulation:

1. Take 3 bytes of input — That's 24 bits of binary data.
2. Split into 4 groups of 6 bits — Each 6-bit value ranges from 0 to 63.
3. Map each value to a character — 0-25 = A-Z, 26-51 = a-z, 52-61 = 0-9, 62 = +, 63 = /.
4. Pad if needed — If the input length isn't divisible by 3, the output is padded with = characters. One leftover byte produces two characters + "==". Two leftover bytes produce three characters + "=".

For example, the text "Hi" (two bytes: 0x48 0x69) becomes "SGk=" in Base64. The padding = indicates there was one leftover byte in the last group.

Decoding is the exact reverse: take 4 Base64 characters, map them back to 6-bit values, concatenate the bits, and split into bytes. Every programming language has built-in Base64 encode/decode functions, so you never need to implement this yourself.

Base64 appears in many contexts across web development:

Data URIs in HTML/CSS — Small images can be embedded directly in HTML or CSS as data URIs: data:image/png;base64,iVBOR.... This eliminates an HTTP request, which is useful for tiny icons (under ~2KB). For larger images, a separate file is more efficient because Base64 adds 33% overhead and prevents browser caching.

Email attachments (MIME) — Email protocols are text-based, so binary attachments (images, PDFs, zip files) are Base64-encoded before being embedded in the email. Your email client handles this transparently.

API payloads — When an API needs to accept or return binary data within a JSON body, Base64 is the standard approach. File upload endpoints often accept Base64-encoded file content. JWTs use Base64URL encoding for their header and payload sections.

Storing binary in text databases — If you're working with a system that only supports text storage (some key-value stores, CSV files), Base64 lets you store binary data. This is a workaround, not a best practice — use binary-capable storage when possible.

Source code — Small binary resources (certificates, icons) are sometimes embedded as Base64 strings in source code to avoid managing separate binary files. This keeps everything in one file but makes the code harder to read.

Standard Base64 uses + and / characters, which have special meanings in URLs (+ means space, / is a path separator). This is a problem when Base64 data needs to be in a URL query parameter or path segment.

Base64URL (RFC 4648) solves this by replacing + with - and / with _. It also typically omits the padding = characters, since the decoder can infer the padding from the string length.

JWTs use Base64URL encoding, which is why JWT tokens contain dashes and underscores but never plus signs or slashes. If you're implementing JWT handling manually, make sure you're using Base64URL, not standard Base64.

Most modern Base64 libraries offer both standard and URL-safe variants:

• JavaScript: btoa()/atob() for standard; manual replacement or a library for URL-safe
• Python: base64.b64encode() for standard; base64.urlsafe_b64encode() for URL-safe
• Go: base64.StdEncoding vs base64.URLEncoding

When in doubt about which variant to use: standard Base64 for general purposes, Base64URL when the data will appear in URLs, tokens, or filenames.