FlowingDev

Base64, explained: the universal translator for binary data

Learn how Base64 encoding turns binary data like images and files into plain text, making it safe to transmit over systems designed only for text.

Try the tool: Base64 Tools

In one sentence

Base64 is a clever way to disguise any binary data (like an image or a zip file) as boring old plain text so it can travel safely through systems that only understand text.

The problem it solves

Picture the internet in its early days. Many of the core systems, like email (SMTP) and the protocols that built the web, were designed with a simple assumption: they would only ever handle text. Specifically, they were built around the 7-bit ASCII character set—the 128 letters, numbers, and symbols you see on a standard English keyboard.

This was fine for sending messages, but what happens when you want to send something that isn't simple text? An image, a sound file, a program? That data is binary. It's a stream of bytes where any of the 256 possible values for a byte can appear. The problem is, some of those byte values are also used as special control characters in text-based systems. For example, a byte might signal "end of transmission" or "start of a new line."

If you tried to send a raw image file through an old email server, the server might see a random byte in the middle of your image data that it interprets as "OK, message over!" and chop the rest of your file off. Your beautiful cat picture arrives as a garbled mess of digital static, if it arrives at all.

This is the problem Base64 was born to solve. It was introduced as part of the MIME (Multipurpose Internet Mail Extensions) standard to create a "safe" alphabet of characters that could be trusted by any text-handling system. By encoding binary data into this limited set of characters, you could effectively put your fragile data into a standardized, sturdy shipping container that the postal system (the text-based protocol) wouldn't mess with.

How it works under the hood

Base64 isn't magic, and it's definitely not encryption. It's just a systematic, reversible substitution cipher. It trades storage efficiency for transport safety, making the data about 33% larger in the process.

Let's walk through encoding the simple word "Man".

From bytes to bits

First, we take our input string and get its binary representation. In ASCII/UTF-8, "Man" is three bytes:

Character ASCII Code 8-bit Binary
M 77 01001101
a 97 01100001
n 110 01101110

We then squish these together into a continuous stream of 24 bits (3 bytes x 8 bits/byte): 010011010110000101101110

The 6-bit shuffle

Here's the core trick. Instead of reading this stream in 8-bit chunks (bytes), Base64 reads it in 6-bit chunks. Why 6? Because 2^6 is 64, which gives us exactly 64 different possible values for each chunk.

So, we regroup our 24-bit stream: 010011 010110 000101 101110

Now we have four 6-bit chunks. We can convert each of these back to a decimal number:

6-bit chunk Decimal Value
010011 19
010110 22
000101 5
101110 46

The lookup table

The final step is to map these decimal values to the 64-character "safe" alphabet of Base64. This alphabet consists of A-Z (indices 0-25), a-z (indices 26-51), 0-9 (indices 52-61), and two special characters, + and / (indices 62 and 63).

Index Char Index Char Index Char Index Char
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
... ... ... ... ... ... ... ...
19 T 22 W 5 F 46 u
... ... ... ... ... ... ... ...

Looking up our decimal values:

  • 19 maps to T
  • 22 maps to W
  • 5 maps to F
  • 46 maps to u

So, the Base64 encoding of "Man" is TWFu.

Dealing with leftovers (padding)

That worked perfectly because our input ("Man") was 3 bytes long, which is a nice multiple of 24 bits. 24 is divisible by both 8 and 6, so everything lines up. But what if the input isn't a multiple of 3 bytes?

This is where the = padding character comes in. Base64 requires that the final encoded string represent a whole number of 3-byte input groups. If the original data doesn't end on a 3-byte boundary, padding is added to the output to make it the right length.

  • If your input has one byte: e.g., "M" (01001101). We take the 8 bits, grab the first 6 (010011, which is T), and are left with 2 bits (01). Base64 says you must pad these 2 bits with four 0s to make a full 6-bit chunk (010000, which is Q). Since we needed to add padding bits, we also add padding characters to the final string. The rule is to add = until the output string's length is a multiple of 4. So, "M" becomes TQ==.
  • If your input has two bytes: e.g., "Ma" (0100110101100001). We have 16 bits. We can make two full 6-bit chunks (010011 -> T, 010110 -> W). We're left with 4 bits (0001). We pad them with two 0s to make 000100, which is E. We add one = to the output to make its length a multiple of 4. So, "Ma" becomes TWE=.

The = padding doesn't represent any actual data, but it's crucial for decoders to correctly reconstruct the original binary.

Real-world stories

The self-contained web page

A UX designer wants to create a simple, single-file prototype of a webpage to share with a client. The page needs the company logo and a specific brand font to look right. Normally, this would mean creating an HTML file, an image file (logo.png), and a font file (brand-font.woff2), then zipping them all up.

Instead, the designer uses an online tool to Base64-encode the logo and the font. They embed the resulting text strings directly into the stylesheet using data: URIs:

.logo {
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...");
}

@font-face {
  font-family: 'BrandFont';
  src: url("data:font/woff2;base64,d09GMgABAAAAAAbwAA...") format('woff2');
}

Now, they can send a single .html file to the client. When the client opens it in their browser, the page renders perfectly with the logo and custom font, no extra files or web server needed.

The lesson: Base64 is perfect for bundling small binary assets (images, fonts, icons) directly into text files like HTML, CSS, or SVG, creating portable, self-contained documents and reducing HTTP requests.

The API that speaks only JSON

A backend service generates PDF invoices for customers. The frontend web application needs to fetch this invoice and let the user download it. The problem is, the API that connects the backend and frontend is a modern REST API that communicates exclusively in JSON. JSON is great with strings, numbers, and booleans, but it has no native way to represent a raw PDF file.

The backend developer solves this by taking the binary PDF data, Base64-encoding it, and placing the resulting massive string inside a JSON object:

{
  "invoiceId": "INV-2024-00123",
  "customer": "ACME Corp",
  "fileData": "JVBERi0xLjcKJeLjz9MKMSAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFn..."
}

When the frontend receives this JSON, it reads the fileData string, decodes it from Base64 back into the original binary PDF data, and uses a browser API to trigger a file download for the user.

The lesson: Base64 is the lingua franca for tunneling binary data through text-only formats like JSON and XML. It's the standard way to handle file uploads/downloads via APIs.

The short-lived secret in the URL

You've seen them a million times: password reset links. A typical link might look like https://example.com/reset?token=.... That token often needs to carry several pieces of information: the user's ID, an expiration timestamp, and a cryptographic signature to prevent tampering.

Combining these pieces might result in a string of binary data. You can't just plop raw binary data into a URL; it would be garbled or rejected. The solution is to Base64-encode the binary token. This is exactly what standards like JWT (JSON Web Tokens) do. A JWT is made of three Base64-encoded parts joined by dots.

But there's a catch! The standard Base64 alphabet includes + and /. These characters have special meanings in URLs and can break routing. This led to the creation of a "URL-safe" Base64 variant, which replaces + with - and / with _.

The lesson: Base64 makes binary data safe for URLs, but you must use the URL-safe variant to avoid conflicts with reserved characters.

Common mistakes and traps

  • "It's encryption!" No, it's not. This is the number one misconception. Base64 is an encoding, not encryption. It offers zero confidentiality. It's like writing a message in pig latin—anyone who knows the simple rule can reverse it instantly. Never use Base64 to hide secrets; use actual cryptography for that.
  • Bloating your data. Base64 encoding increases the data size by roughly 33% (because every 3 bytes of input become 4 bytes of output). For small icons or tokens, this is negligible. For a 10 MB video file, you're adding over 3 MB of overhead. This can make API responses slow and increase bandwidth costs.
  • Forgetting about URL-unsafe characters. If you're putting Base64-encoded data into a URL query parameter or path segment, you must use the URL-safe variant (which replaces + and /) or otherwise URL-encode the output. A stray + can be misinterpreted as a space, and a / can be seen as a path delimiter, leading to broken links and 404 errors.
  • Mishandling padding. While many modern decoders are lenient about missing = padding, the specification requires it for correctness. Stripping or incorrectly calculating padding can cause strict decoders to fail. It’s best to treat the padding as part of the encoded string.

Why it belongs on your radar

You should think of Base64 anytime you're faced with this core dilemma: "I have binary data here, but I need to send it through a channel that only speaks text." It’s a fundamental tool for data transport and compatibility.

Reach for it when you need to:

  • Embed small images, SVGs, or fonts directly in HTML/CSS.
  • Send a file (PDF, image, etc.) within a JSON or XML payload.
  • Encode binary data for use in a URL or cookie.
  • Work with standards like JWTs, which use Base64 as a building block.

It's not something you use every day, but knowing what it is and when to use it will save you from countless hours of debugging garbled data and mysterious transmission errors.

Go deeper

Theory done. Time to get your hands dirty — 100% in your browser.

Try the tool: Base64 Tools