What Is Base64 and Why Do Developers Use It?

Base64 is a way of writing binary data using only 64 printable characters. That is the whole idea. It is not encryption, not compression, and not a file format — it is a re-spelling, so that bytes which would break a text-only channel can pass through it unharmed.

You have seen its output even if you never learned the name: the long iVBORw0KGgo... string behind an inlined image, the three dot-separated chunks of a JWT, the Authorization: Basic dXNlcjpwYXNz header. This post explains what those strings are and how they are built. For how Base64 fits alongside URL encoding, HTML entities, and UTF-8, start with The Complete Guide to Text Encoding on the Web.

The problem it solves

Bytes range from 0 to 255. Many of those values are hostile to text channels: control characters that terminate strings, byte 0x0A that old mail servers treated as a line break, values above 127 that some intermediary might "helpfully" reinterpret under a different charset.

Historically, email was the forcing function. SMTP was designed for 7-bit ASCII, so attaching a photo meant finding a representation using only safe characters. MIME standardized Base64 for that job, and the same trick turned out to solve the same problem everywhere else: JSON has no binary type, HTTP headers must be ASCII, XML documents choke on stray control bytes, and data: URIs live inside URLs.

Base64's alphabet is deliberately conservative: A-Z, a-z, 0-9, +, /, with = reserved for padding. Sixty-four characters that essentially every system on earth agrees about.

How the encoding works

Take the ASCII string Man — three bytes: 77, 97, 110.

Write them in binary and run them together as one 24-bit block:

01001101 01100001 01101110

Now split that block into four groups of 6 bits instead of three groups of 8:

010011 010110 000101 101110
   19     22      5     46

Look each number up in the alphabet — index 19 is T, 22 is W, 5 is F, 46 is u — and you get TWFu.

Three bytes in, four characters out. No exceptions. That fixed ratio is where the roughly 33 percent size increase comes from: you are spending 8 bits of output space to carry 6 bits of input.

Padding

Inputs are rarely a multiple of 3 bytes long. When the final chunk is short, the remaining bits are zero-filled and the output is padded with = to keep its length a multiple of 4:

• Man (3 bytes) → TWFu — no padding
• Ma (2 bytes) → TWE= — one =
• M (1 byte) → TQ== — two =

The padding carries no data. It exists so a decoder reading a concatenated stream knows where one encoded unit ends. You can watch this happen live in the Base64 Encoder / Decoder — type one character, then two, then three, and watch the = signs disappear.

Base64 encodes bytes, not characters

This trips people up constantly. Base64 has no concept of text. Before you can encode a string, something has to turn that string into bytes using a character encoding — almost always UTF-8.

So café becomes the five UTF-8 bytes 63 61 66 C3 A9, and those get Base64-encoded. If you encode with UTF-8 and decode as Latin-1, you get café back. The Base64 layer worked perfectly; the charset assumption underneath it did not.

The practical rule: fix your character encoding first, then apply Base64. Mismatches at this seam are one of the more common sources of garbled text in systems that pass encoded blobs around.

Where you actually meet it

Data URIs. <img src="data:image/png;base64,iVBOR..."> embeds an image directly in HTML or CSS, removing a network request. Worth it for small icons; counterproductive for anything large, since the payload grows by a third and cannot be cached separately. The Image to Base64 converter produces these strings from a local file without uploading it.

JWTs. A JSON Web Token is three Base64URL-encoded segments joined by dots. The header and payload are plain JSON, readable by anyone — the signature is what makes the token trustworthy, not the encoding.

HTTP Basic auth. Authorization: Basic followed by Base64 of username:password. This is obfuscation, not protection, which is why Basic auth is only acceptable over HTTPS.

Email attachments and binary in JSON. Same motivation in both cases: the container is text, the payload is not.

The URL-safe variant

Standard Base64 uses + and /, and both are problematic in URLs — / is a path separator and + means a space in form-encoded query strings. Putting raw Base64 in a URL means percent-encoding it as well, which inflates the size again and makes the value unreadable.

Base64URL fixes this by substituting - for + and _ for /, and typically omitting the = padding (which would otherwise become %3D). It is the same 6-bit math with two characters swapped. JWTs, OAuth state parameters, and URL-safe identifiers all use it, and the Base64URL Encode / Decode tool handles the variant directly. If you are working with query parameters generally, URL encoding explained covers the surrounding rules.

Relatives: hex and Base32

Base64 sits on a spectrum of alphabet sizes:

Encoding	Alphabet	Size increase	Typical use
Hex	16 chars	100%	Hashes, colour codes, byte inspection
Base32	32 chars, case-insensitive	60%	TOTP secrets, DNS-safe identifiers
Base64	64 chars	33%	General binary-in-text

Smaller alphabets are more robust — Base32 survives being read aloud, typed by hand, or passed through case-insensitive systems, which is why authenticator app secrets use it. Larger alphabets are more compact. Base32 and Base64 trade the same two properties in opposite directions.

What Base64 is not

It is not encryption. There is no key. The transformation is public and fully specified, so anyone holding the string can recover the original in one step. A Base64-encoded password is a plaintext password with an extra step — a point worth reading in full in Base64 is not encryption.

It is not compression. It reliably makes data larger, never smaller. If you need both smaller and text-safe, compress first, then Base64 the compressed bytes.

It is not a hash. Hashes are one-way and fixed-length. Base64 is two-way and proportional to its input.

Decoding without uploading anything

Base64 strings routinely contain exactly the material you should not be pasting into an unknown server — tokens, credentials, customer payloads, internal config. Many online decoders send your input to a backend to do work that takes a browser under a millisecond.

Our encoder and decoder run entirely client-side. The string you paste stays in the tab, never reaches a server, and never appears in a log. If you want to verify it, open your browser's network panel while you type, or turn off your connection and use the page anyway.