Base64 Encoding, Explained

What Base64 actually is

Computers store everything — images, fonts, executables, encrypted blobs — as raw bytes, and a byte can hold any of 256 values. Many systems, however, were built to move only text: classic email, the headers of HTTP requests, the string fields of JSON, the contents of a URL. Feed raw bytes through those channels and the bytes that happen to be control characters, null, or non-ASCII values get mangled or rejected.

Base64 solves this by re-expressing arbitrary binary data using just 64 printable ASCII characters that survive almost anywhere: the uppercase letters A–Z, the lowercase letters a–z, the digits 0–9, and the two symbols + and /. A = character is used for padding. Because every output character is safe, ordinary text plumbing carries the data without corrupting it, and the original bytes can be reconstructed exactly on the other end.

How it works: 3 bytes become 4 characters

The mechanism is pure arithmetic on bits. Take the input 3 bytes at a time. Three bytes are 24 bits. Slice those 24 bits into four groups of 6 bits. A 6-bit group can hold a value from 0 to 63 — exactly 64 possibilities — and each value is mapped to one character of the Base64 alphabet (0 → A, 1 → B, …, 25 → Z, 26 → a, … 62 → +, 63 → /).

So three 8-bit bytes turn into four 6-bit characters. That is where both the simplicity and the 33% size penalty come from: you always emit four characters for every three bytes of input (4 ÷ 3 ≈ 1.33).

Padding: when the input is not a multiple of 3

Input data rarely divides evenly into groups of three. Base64 handles the remainder with = padding so the output length always stays a multiple of four:

• 3 leftover bytes → 4 characters, no padding.
• 2 leftover bytes → 3 characters of data + one =.
• 1 leftover byte → 2 characters of data + two ==.

A worked example

Encode the three-letter string "Man". Its ASCII byte values are M=77, a=97, n=110, which in binary are:

So "Man" encodes to "TWFu" — three bytes in, four characters out, no padding needed. Now drop a letter to see padding appear:

• "Ma" (2 bytes) → "TWE=" — three data characters and one pad.
• "M" (1 byte) → "TQ==" — two data characters and two pads.

You can try this with any text or file using the Base64 encoder/decoder and watch the padding behave exactly as above.

Where you will actually see Base64

Once you know what to look for, Base64 is everywhere binary meets text:

• Email attachments (MIME). SMTP was designed for 7-bit text, so attachments are Base64-encoded to survive the journey through mail servers intact.
• Data URIs. A string like data:image/png;base64,iVBORw0KGgo… embeds an entire image inline, with no separate file or network request.
• Inline images and fonts in CSS/HTML. Small icons or web fonts are sometimes Base64-embedded to cut HTTP round-trips. The image-to-Base64 tool produces these strings directly.
• Binary inside JSON and JWTs. JSON has no native byte type, so raw binary is carried as a Base64 string. JSON Web Tokens encode their header and payload sections this way too.
• HTTP Basic authentication. The browser sends Authorization: Basic followed by the Base64 of username:password — which is exactly why Basic auth must only ever run over HTTPS, since Base64 is trivially reversible.

Base64 vs Base64URL

The standard alphabet's + and / are problematic in some contexts: / is a path separator and + can be interpreted as a space when it appears in a URL query string. The Base64URL variant fixes this by swapping those two characters for URL-safe ones — + becomes - and / becomes _ — and it commonly drops the = padding, since the length can be inferred. This is the form used in JWTs and anywhere a Base64 value must ride safely inside a URL or filename. If you are also wrestling with special characters in links, the URL encoder/decoder handles the related but separate job of percent-encoding.

A few quick conversions

Some short strings and their standard Base64 output, so the padding pattern is easy to see:

The takeaway

Base64 does one narrow job extremely well: it lets binary data pass through text-only pipes without damage, using a fixed 64-character alphabet and predictable = padding. Remember the two things that trip people up — it adds about a third to your data size, and it offers no privacy whatsoever. Treat it as a transport format, reach for real encryption when you need secrecy, and Base64 will quietly do its part.

Frequently asked questions

Is Base64 a form of encryption?

No. Base64 is a reversible encoding with no secret key, so anyone can decode it instantly. It hides nothing and provides zero security. It exists only to move binary data safely through text-based channels — never use it to protect passwords, tokens, or any sensitive data.

Why does Base64 make data bigger?

Base64 turns every 3 bytes of input into 4 output characters, so the encoded form is about 33% larger than the original. Padding and line breaks can add a little more. That overhead is the price of expressing arbitrary bytes using only printable ASCII characters.

What are the = signs at the end of a Base64 string?

They are padding. Base64 works in groups of 3 input bytes that become 4 characters. When the final group has only 1 or 2 bytes, the output is padded with = to keep the length a multiple of 4. One leftover byte gives two = signs; two leftover bytes give one =.

What is the difference between Base64 and Base64URL?

Base64URL is a variant designed to travel safely in URLs and filenames. It replaces the + and / characters with - and _, which have no special meaning in those contexts, and it usually drops the = padding. JSON Web Tokens (JWTs) use Base64URL for exactly this reason.

This guide is general technical information. Base64 is an encoding for safe transport of binary data, not a security mechanism — use proper encryption for anything that must stay private.