What Is Base64? How an Image Turns Into a String of Text

What Base64 is in plain English

Base64 is a way to write any data using just 64 safe characters: Latin letters, digits and a couple of symbols. The one thing to grasp up front is this: Base64 is not an image format. It is an encoding — a wrapper around a file. The image itself does not change; only its written form does. Instead of cryptic bytes you get a long string of letters and digits that you can paste anywhere as ordinary text.

Imagine you had to read out the contents of a photo to a friend over the phone. Reading out raw bytes is impossible — they are full of "unprintable" values. But a string of A–Z, a–z, digits and two symbols can absolutely be dictated. Base64 solves exactly that: it converts "unspeakable" data into text that travels cleanly through channels designed for letters only.

Why turn data into text at all

Many systems have historically only understood text. Email was invented to carry plain text only — a limited set of basic letters and symbols, nothing more; JSON is a text format; a URL is text too. Try to stuff raw image bytes into any of them and something will break: one of the bytes will collide with a control character and the data gets mangled.

Base64 is a universal adapter. It guarantees the result contains no "dangerous" characters, so the data arrives intact. That is why the encoding has been in use for decades: email attachments, authorization tokens, embedded images on web pages — anywhere binary data has to masquerade as text.

The trick is actually much older than the web. Back in the 1990s it was standardized for email (the MIME scheme) so attachments could travel over channels built for 7-bit text only. So when you attach a photo to an email, it almost certainly travels to the recipient as Base64 — your mail client just hides that from view.

How it works: 3 bytes → 4 characters

The principle is surprisingly simple. The computer takes data in chunks of 3 bytes (that is 24 bits) and slices them not into 8-bit pieces as usual, but into 6-bit ones. That gives exactly four pieces of 6 bits each. Every piece is a number from 0 to 63, and the Base64 alphabet has one character for each of those numbers.

Take the short word Man. Every letter has a number the computer uses for it — for these three it's 77, 97 and 110. In binary: 01001101 01100001 01101110. Regroup into 6-bit chunks: 010011 010110 000101 101110. Those are the numbers 19, 22, 5 and 46. In the Base64 table they map to T, W, F, u. The result: Man becomes TWFu.

"Man"  →  01001101 01100001 01101110
       →  010011 | 010110 | 000101 | 101110
       →    19   |   22   |   5    |   46
       →    T    |   W    |   F    |   u
"Man"  →  "TWFu"

An image works the same way, just with millions of bytes. The program simply runs the whole file through this "3 bytes → 4 characters" conveyor from start to finish, and out comes one long text string.

The alphabet and those mysterious = signs

The standard Base64 alphabet is defined in the specification RFC 4648 and consists of 64 characters in strict order: first the uppercase A–Z (numbers 0–25), then lowercase a–z (26–51), then the digits 0–9 (52–61), and finally two symbols — + (62) and / (63).

So what happens when the data does not divide evenly into 3-byte groups? Then = signs appear at the end — this is padding. A single = means the last block had 2 bytes; two == mean it had just 1 byte. These characters carry no data; they only tell the decoder how to rebuild the tail correctly.

Data URIs: an image inside an address

The most useful web application of Base64 is the data URI (defined in RFC 2397). Normally an image is linked by reference — src="logo.png" — and the browser goes off to fetch the file from the server. A data URI flips the idea: instead of a link to a file, you put the data itself right into the address.

It looks like this: data: + the data type + ;base64, + the string itself. For example:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg
AAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9
awAAAABJRU5ErkJggg==">

The browser sees that src, realizes "the data is already here," and draws the image without a separate request to the server. The same string works in CSS too — for instance background: url(data:image/png;base64,…). This is how you "weld" an image straight into the page.

Why the text is heavier than the file

The neat trick has a cost. Because we encode every 3 bytes as four characters, the resulting string ends up exactly a third longer than the original data — a growth of about +33%. A 9 KB image becomes a string of roughly 12 KB.

That is why Base64 is great for small things — icons, tiny background textures, SVG glyphs. For large photographs the extra 33% and the loss of caching usually outweigh the benefit. We dig into that trade-off in "Base64 images on the web" and compare it with plain files in "Base64 vs image files".

How to encode an image

Nobody counts bits by hand, of course. The easiest path is to drop the file into an online converter and get back a ready-to-use data URI string that you can paste straight into your code.

If instead you have a Base64 string and need to get a normal file out of it, the reverse conversion Base64 to PNG has you covered. And every available converter lives on the all formats page.