Base64 is one of those pieces of internet plumbing that most people have run into without knowing its name — that long, jumbled-looking string of letters, numbers, plus signs and slashes that shows up in email attachments, image data URLs, and API authentication headers. It looks like it might be encryption or compression. It's neither.

What Base64 actually does

Base64 takes binary data — raw bytes, the kind of data an image, a file, or any non-text content is made of — and re-represents it using only 64 safe, printable characters: uppercase and lowercase letters, digits, and typically + and / (with = used for padding at the end). The reason this matters is that a lot of older systems, protocols and text-based formats were only ever designed to reliably carry plain text — they choke on or mangle certain raw binary byte sequences. Base64 sidesteps the problem entirely by converting binary into something that's guaranteed to be plain, safe text.

Why it's not encryption

This is the most common misconception about Base64, and it's an important one to clear up: Base64 encoding provides zero security. It's fully reversible by anyone, instantly, with no key or password required — decoding it is exactly as easy as encoding it. If you've ever seen a password or API token stored as a Base64 string and assumed it was "encoded for safety," that assumption is wrong; anyone who copies that string can decode it in seconds using a tool exactly like the one linked below. Base64 is about compatibility, not confidentiality.

Why it's not compression either

The other common assumption — that encoding something makes it smaller — is also backwards. Base64 actually increases the size of the data by roughly 33%, because it's re-packing 8-bit bytes into a smaller, safer 6-bit-per-character alphabet, which takes more characters to represent the same information. This tradeoff is worth it specifically because compatibility (getting the data through safely) is usually more valuable in these contexts than saving space.

Where you actually encounter it

  • Email attachments (MIME). Email was originally a plain-text protocol; attaching an image or a PDF requires converting that binary file into Base64 text so it survives being routed through mail servers designed for text.
  • Data URLs in web pages. An image embedded directly into HTML or CSS as data:image/png;base64,... avoids a separate network request, at the cost of a larger file.
  • API authentication headers. Basic HTTP authentication sends a username and password as a Base64 string in a request header — again, purely for encoding compatibility, not for security, which is exactly why this scheme is only considered safe over an encrypted HTTPS connection.
  • Storing binary data in text-only fields. Some databases, config formats, or JSON payloads can only hold text; Base64 lets binary data ride along inside a plain string field.

The practical takeaway

If you see Base64 anywhere, the correct mental model is "this data has been repackaged to travel safely through a text-only channel," not "this data has been protected." Treat anything Base64-encoded exactly as sensitively as you'd treat the original raw data, because functionally, it still is that data.

A worked example, step by step

Take the plain text "Hi". Each character is first converted to its underlying byte value — 'H' is 72, 'i' is 105 — which in binary is 01001000 01101001, 16 bits total. Base64 regroups this bit stream into 6-bit chunks rather than the original 8-bit bytes: 010010 000110 1001. The last group only has 4 bits, so it gets padded with zeros to make 6: 010010 000110 100100. Each 6-bit chunk (a value from 0–63) maps to one character in the Base64 alphabet, giving SGk= as the final encoded output for "Hi" — the trailing = is padding, added because the original data didn't divide evenly into 3-byte groups (Base64 processes input in chunks of 3 bytes → 4 output characters). You'll never need to do this by hand, but seeing the mechanism once makes the "why does it get longer" question click immediately: you're trading 8-bit efficiency for 6-bit safety.

The URL-safe variant

Standard Base64's + and / characters happen to carry special meaning inside URLs (+ often represents a space, / separates path segments), which causes problems if you try to drop a Base64 string directly into a URL or filename without extra escaping. To work around this, a URL-safe variant of Base64 exists that simply swaps those two characters for - and _, and often omits the trailing padding = characters entirely, since URL contexts frequently don't need them. It's the same underlying encoding — just a different, more URL-friendly choice of which 64 characters to use as the alphabet, and it's the version you'll see used in things like JSON Web Tokens (JWTs), where the encoded data is a routine part of a web address or HTTP header.

Try it yourself

Our Base64 Encoder/Decoder converts text or files in either direction, entirely in your browser, with nothing uploaded anywhere.

Related reading