Base64 is one of those terms developers use constantly and rarely stop to explain. In plain English, it is a way to represent binary data — images, files, cryptographic keys — using only ordinary text characters, so that data can pass safely through systems that were built to handle text and nothing else.
This guide explains why Base64 exists, where it is genuinely useful, the single most important thing it is not (a security measure), how it differs from URL encoding, and how to encode or decode data yourself in seconds.
Many older but still-essential systems — email, and parts of the web — were designed for plain text and can corrupt or reject raw binary data. Send an image straight through such a channel and bytes get mangled, because the system interprets certain values as control characters rather than data.
Base64 solves this by translating any sequence of bytes into a safe alphabet of 64 characters: A–Z, a–z, 0–9, and two symbols. Every possible byte maps onto these harmless characters, so the data survives the journey intact and can be decoded back to the original on the other side.
Base64 is not free. Because it represents three bytes of data using four text characters, the encoded output is about 33% larger than the original. That overhead is the price of safety.
For small pieces of data the cost is negligible and well worth it. For large files it adds up, which is why Base64 is used for embedding small assets and transmitting modest payloads rather than as a general-purpose way to move big files around.
You encounter Base64 far more often than you might realise:
Paste text into the Base64 Encoder/Decoder to convert it in either direction — encode plain text to Base64, or decode a Base64 string back to its original. It runs locally, so nothing you enter is sent anywhere.
To turn a picture into a data URI you can paste straight into your HTML or CSS, use the Image to Base64 tool. It reads the image in your browser and outputs the ready-to-use encoded string, which is handy for small icons and logos that you want to inline for speed.
This is the most important point in the whole topic. Base64 is encoding, not encryption. Anyone can decode a Base64 string instantly with a free tool — there is no key and no secret involved. It scrambles nothing.
People sometimes confuse the two because both make data "safe," but they solve different problems. Base64 makes arbitrary binary data safe to place in a text channel. URL encoding makes text safe to place inside a web address by escaping characters that have special meaning there — turning a space into %20 and an ampersand into %26, for instance.
If your task is putting a value into a query string or a link rather than transmitting binary data, reach for the URL Encoder/Decoder instead. Choosing the right one avoids the double-encoding bugs that trip up a lot of developers.
Seeing Base64 in action makes the concept click. Take the simple word "Hi". In the computer's memory this is two bytes, whose values happen to be 72 and 105. Base64 works by regrouping the bits of those bytes into chunks of six, and mapping each chunk onto its 64-character alphabet.
The two bytes of "Hi" become the Base64 string "SGk=". The trailing "=" is padding, added because Base64 works in groups of four output characters and the input did not divide evenly. Decode "SGk=" and you get "Hi" back, exactly. You do not need to do this by hand — the Base64 Encoder/Decoder handles it instantly — but understanding that Base64 is simply a reversible regrouping of bits, not a transformation of meaning, explains both why it is perfectly reliable and why it offers no secrecy whatsoever.
There is not just one Base64. The standard alphabet uses the characters "+" and "/" as its last two symbols, which is fine in most contexts but causes problems in URLs, where those characters have special meaning. To solve this, a variant called Base64URL replaces them with "-" and "_", making the output safe to drop straight into a web address or filename.
You will meet Base64URL most often in web tokens, such as the parts of a JSON Web Token, where encoded data travels inside URLs and headers. The two variants are otherwise identical and equally easy to decode. If a Base64 string fails to decode cleanly, a mismatch between standard and URL-safe variants is a common culprit — and worth checking before assuming the data itself is corrupt.
One of the most visible uses of Base64 on the web is the data URI, which embeds a small file — usually an image — directly into HTML or CSS as an encoded string, rather than linking to a separate file. This has genuine benefits and real drawbacks, and knowing when to use it is a useful judgement.
The advantage is one fewer network request. Every separate file a page loads has some overhead, so inlining a tiny icon or logo as a data URI can make a page render marginally faster, and it keeps the asset bundled with the code that uses it. For very small, frequently-used images this can be worthwhile.
The drawbacks grow with size. Because Base64 inflates data by about a third, inlining anything but small images bloats your HTML or CSS. Worse, an inlined image cannot be cached separately by the browser, so it is re-downloaded every time the page loads instead of being stored once and reused. The practical rule: reserve data URIs for small, static images like icons — generated conveniently with the Image to Base64 tool — and link to normal image files for anything larger, where separate caching and smaller file size matter more than saving a request.