Base64 Encoding Explained

What it actually does, how the math works, and when you should (and shouldn't) use it.

What Base64 Actually Is

Base64 is a way to represent binary data using only text characters. That's it. It takes any sequence of bytes and converts it into a string made up of letters (A-Z, a-z), numbers (0-9), plus signs, and forward slashes. The equals sign shows up at the end for padding.

It was designed to solve a specific problem: how do you send binary data through systems that only understand text? Email was the original use case. SMTP was built for ASCII text, and binary attachments would get mangled in transit. Base64 gave us a reliable way to encode those files as plain text.

The Math Behind It

Here's how the conversion works. Take 3 bytes of input data - that's 24 bits. Split those 24 bits into four groups of 6 bits each. Each 6-bit group maps to one of 64 characters in the Base64 alphabet. So 3 bytes of input become 4 characters of output.

This is where the 33% size increase comes from. Every 3 bytes turn into 4 characters. If your input isn't divisible by 3, padding characters (=) get added to fill things out. A single byte becomes 4 characters with two padding chars. Two bytes become 4 characters with one padding char.

The 64-character alphabet is specifically chosen because 2^6 = 64. Six bits per character is the sweet spot - large enough to be reasonably compact, small enough that every character is a printable ASCII character safe for transport.

Where You'll See Base64

It shows up everywhere in web development:

• Data URIs - Embedding small images directly in CSS or HTML. data:image/png;base64,iVBOR... avoids an extra HTTP request.
• Email attachments - Still the original use case. Every attachment you send is Base64-encoded under the hood.
• Authorization headers - HTTP Basic Auth encodes username:password as Base64. This is encoding, not encryption - anyone can decode it.
• JWTs - JSON Web Tokens use Base64url encoding (a URL-safe variant) for the header and payload sections.
• API payloads - When you need to send binary data in a JSON body, Base64 is the standard approach.

What Base64 Is NOT

This is where developers get tripped up. Base64 is not encryption. It's not security. It's not compression. Let's be clear about each one.

It's not encryption because there's no key. Anyone can decode a Base64 string instantly. If you're "hiding" passwords or API keys with Base64, you're not protecting anything.

It's not compression - it actually makes data bigger. That 33% overhead means a 1MB file becomes roughly 1.33MB after encoding. If you need to shrink data, use gzip or brotli.

It's not a hash either. Base64 is fully reversible. You can always get the original data back, which is the opposite of what hashing does.

Common Mistakes

Double encoding. This happens when you Base64-encode something that's already Base64-encoded. The output looks valid but decoding it once gives you gibberish. Check your pipeline.

Using it for large files. Inlining a 500KB image as a data URI is almost always worse than just loading the file normally. The Base64 version is bigger, can't be cached separately, and blocks rendering. Keep data URIs under 5-10KB.

Assuming URL safety. Standard Base64 uses + and / which aren't URL-safe. If you're putting Base64 in URLs, use the Base64url variant that substitutes - and _ instead.

Treating it as security. Worth repeating. Don't store passwords or tokens as Base64. Use proper encryption or hashing.

Try It Yourself

← Back to all tools