Base64 Encoder & Decoder

Base64 is not encryption

This is the single most important thing to know about Base64, and it is the reason this page says it in three places. Base64 is an encoding. There is no key, no secret, and nothing to keep safe. Every Base64 string can be turned back into what it was by anyone, using a tool like this one, in about a second.

It is genuinely useful for moving data through text-only channels, and it is genuinely useless for hiding it. If you need something to be confidential, it needs to be encrypted — HTTPS, or encryption designed for the job.

How the alphabet works

There are 64 printable characters used as digits: A–Z, a–z, 0–9, then `+` and `/`. Every three bytes of input become four characters, and the leftover bytes are padded with `=` to the end.

"Hel"  ->  SGVs
"llo"  ->  bGxv        (three groups, no padding)
"lo!"   ->  bG8=        (two bytes left, so one = pads the group)

That padding is why a Base64 string's length is always a multiple of four, and why one that is not was truncated somewhere in transit.

base64url, and when you need it

Standard Base64 uses `+` and `/`, and both are awkward in a URL: `+` is read as a space in a query string, and `/` is read as a path separator. Base64url swaps those two characters for `-` and `_` and drops the padding, which makes the result safe to drop into a URL, a JWT, or a filename unescaped.

Worth knowing, because it surprises people: for plain ASCII text the two encodings are identical apart from the padding. The `-` and `_` characters only ever appear when the input contains bytes above 127, so a text-only string will not show you the difference at all.

Line wrapping

Long Base64 strings are often broken into lines, because some channels cannot hold a single unbroken line of text. Both common widths are multiples of four — 76 for MIME (an email attachment) and 64 for PEM (a certificate or key) — so each line can be decoded on its own.

This decoder ignores whitespace entirely, so it reads wrapped input, unwrapped input, and input with the two mixed, without complaint.

When the result is not text

A Base64 string can hold any bytes at all, and many of the things people decode are files rather than text: an image, a font, a compressed archive, a private key. Those bytes are not valid UTF-8, so there is no honest way to show them as characters.

Rather than display replacement characters and let you copy something that no longer matches the input, this page says so and shows the bytes as hex. To get the real file back, decode it to bytes rather than to text:

echo 'iVBORw0KGgoAAAANSUhEUg==' | base64 -d > image.png

# -d decodes to bytes. Without it, base64 writes the decoded text and
# corrupts anything that is not valid UTF-8.

Doing it by hand

Worth doing once, because it makes clear there is nothing magic happening. In a terminal, `base64` and `base64 -d` are the whole story:

echo -n 'Hello, world!' | base64          # SGVsbG8sIHdvcmxkIQ==
echo -n 'Hello, world!' | base64 -d       # Hello, world!
echo -n 'Hello, world!' | base64 | base64 -d   # round trip

# Node, if you would rather not leave the terminal
node -e 'console.log(Buffer.from("hi").toString("base64"))'

One trap in the shell version: `echo` adds a trailing newline, so `echo 'hi' | base64` encodes two characters rather than one. Use `echo -n` when the exact bytes matter.