Base64 Encoder & Decoder

What Base64 is for

Base64 turns arbitrary bytes into 64 safe ASCII characters (A–Z, a–z, 0–9, plus two symbols). It exists so binary data can travel through channels that only expect text — data URIs in CSS, image bytes inside JSON, email attachments, basic-auth headers. The trade-off is size: the output is about 33% larger than the input.

Turning bytes into characters

Base64 reads data three bytes (24 bits) at a time and re-slices those 24 bits into four 6-bit groups. Six bits can hold 64 values, so each group maps to one character of the alphabet. Three bytes in always become four characters out — which is where the roughly one-third size increase comes from. When the input is not a multiple of three bytes, the encoder adds one or two = signs as padding; URL-safe Base64 usually drops them.

A worked example

The three letters Cat are the byte values 67 97 116 (decimal) — that is 0x43 0x61 0x74 in hex. As bits: 01000011 01100001 01110100. Regroup into four 6-bit chunks — 010000 110110 000101 110100 — giving indexes 16, 54, 5 and 52, which are Q, 2, F and 0. So Cat encodes to Q2F0.

Encoding Base64 in different languages

The runtime usually has this built in. Note the JavaScript line: bare btoa only handles Latin-1, so the encodeURIComponent wrapper is what lets Unicode survive — the same approach this tool uses.

// JavaScript (browser) — Unicode-safe
const b64 = btoa(unescape(encodeURIComponent("héllo")));
const txt = decodeURIComponent(escape(atob(b64)));

# Python 3
import base64
base64.b64encode("héllo".encode()).decode()
base64.b64decode(b64).decode()

# Command line
echo -n "héllo" | base64
echo -n "aMOpbGxv" | base64 --decode

One practical snag: classic MIME/email Base64 wraps lines every 76 characters. If a decoder rejects such a block, strip the newlines first — this tool ignores whitespace on decode, so wrapped input still works.

Good and bad uses

• Data URIs — embedding a small image or font directly in CSS/HTML to save a request.
• Text-only payloads — carrying binary inside JSON or XML.
• Tokens and headers — HTTP Basic auth and the segments of a JWT.
• Not for large files — the size penalty and encode/decode cost make raw bytes a better choice for anything big.

When inlining with Base64 actually pays off

The tempting trick is to drop an image straight into your CSS or HTML as a data: URI and save an HTTP request. Sometimes that is the right call, often it isn't, and the deciding factor is size. A 1 KB SVG icon or a tiny background pattern inlines beautifully: no extra round trip, no separate cache entry to manage, and the 33% Base64 overhead on something that small is noise. A 400 KB hero photo is the opposite story. Inlined, it now weighs about 530 KB, it can't be cached on its own, it can't load lazily, and it bloats the very HTML or stylesheet the browser needs first to render the page. As a rough line in the sand, inline assets under a few kilobytes and link to anything bigger.

There's also a flavour to get right. JWTs, anything that travels in a URL, and most modern APIs use Base64url, which swaps + and / for - and _ and usually drops the = padding, because a raw + or / would be mangled in a query string. Standard Base64 is fine for email attachments and JSON bodies. Feed standard Base64 where URL-safe is expected and you'll get intermittent, maddening failures that only show up when the data happens to contain a + or /.