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

Encoding vs. Encryption: An Important Distinction

Before diving into Base64, it is critical to understand what encoding is — and what it is not. Encoding transforms data from one format to another using a publicly known, reversible algorithm. Anyone who knows the algorithm can decode it. Encryption, by contrast, transforms data so that only parties with the correct key can read it.

Base64 is encoding, not encryption. A Base64-encoded string provides zero confidentiality. If you need to protect sensitive data, use a proper cryptographic library — not Base64.

Why Was Base64 Invented?

Binary data (images, executables, compressed archives) contains byte values across the full 0–255 range, including non-printable control characters. Many older text-based protocols — SMTP (email), HTTP headers, HTML attributes — were designed to handle only printable ASCII characters (values 32–126). Sending raw binary through these channels would corrupt the data.

Base64 solves this by encoding binary data using only 64 safe, printable ASCII characters: A–Z, a–z, 0–9, +, and /. The result is a longer string of characters that any text-based system can safely transmit.

How the Base64 Algorithm Works

Base64 processes input in 3-byte (24-bit) chunks. Each chunk is split into four 6-bit groups, and each 6-bit group maps to one of the 64 characters in the Base64 alphabet. This is why the name includes “64” — the 64-character alphabet perfectly fits in 6 bits (2⁶ = 64).

Let's encode the word Man step by step:

Combined: 010011010110000101101110 (24 bits). Split into four 6-bit groups: 010011 010110 000101 101110 = 19, 22, 5, 46 → T, W, F, u → Base64: TWFu.

Padding: Why Base64 Output Ends With =

Since Base64 processes 3 bytes at a time, inputs that are not a multiple of 3 bytes require padding. The = character fills the output to the next multiple of 4 characters:

• Input length divisible by 3 → no padding: TWFu
• Input length mod 3 = 1 → two padding chars: TWFuZA==
• Input length mod 3 = 2 → one padding char: TWFuZGVt

Seeing one or two trailing = characters is completely normal and expected in valid Base64.

Size Overhead: 33% Larger

Base64 encodes 3 bytes of input as 4 characters of output. This means Base64-encoded data is approximately 33% larger than the original binary. A 1 MB image becomes about 1.37 MB when Base64-encoded. This overhead is the key tradeoff when deciding whether to use Base64 for embedding assets.

URL-Safe Base64 (Base64url)

Standard Base64 uses + and /, which have special meaning in URLs. Base64url (defined in RFC 4648) replaces them with - and _, and typically omits padding. This variant is used in:

• JWT tokens — Header, payload, and signature are Base64url-encoded.
• OAuth 2.0 PKCE — The code verifier challenge uses Base64url.
• URL parameters — When binary data must be passed in a query string.

When to Use Base64

When NOT to Use Base64

• To hide or protect sensitive data — Base64 is reversible by anyone. Never use it as a security measure.
• For large files — The 33% size overhead, combined with the CPU cost of encoding/decoding, makes Base64 inefficient for large binary assets. Serve files directly over HTTPS instead.
• To compress data — Base64 increases size. If you need compression, use gzip, Brotli, or zstd first, then Base64 if the transport requires it.
• As a database storage format — Store binary data in binary columns (BYTEA, BLOB) rather than encoding it as a Base64 string, which wastes storage and prevents efficient indexing.