Base64 Explained: Encode and Decode Anything

That wall of gibberish ending in == isn't encrypted, hacked or corrupted — it's Base64, one of the most misunderstood workhorses on the web. It hides inside JWTs, email attachments, data URIs and API payloads, and decoding it takes about two seconds once you know what you're looking at.

What Base64 actually is

Base64 is a re-spelling, not a transformation. It takes binary data — any bytes at all — and rewrites them using only 64 safe ASCII characters: A–Z, a–z, 0–9, + and /. Every 3 bytes of input become 4 characters of output, which is why Base64 output is always about 33% larger than the original. The trailing = signs are padding: they fill out the final group when the input length isn't a multiple of three.

Why bother? Because a lot of infrastructure — email systems designed in the 1980s, JSON strings, URLs, XML documents — only reliably transports text. Base64 lets a JPEG, a PDF or a cryptographic key travel through text-only channels without a single byte getting mangled.

Base64 is not encryption

This deserves its own heading because the confusion causes real security incidents. Base64 has no key and no secret — decoding is a fixed, public recipe that any browser runs in one line of JavaScript. "We Base64-encode the password" means "we store the password in plain sight with extra steps." If you need secrecy, you need actual encryption; if you need binary-safe transport through text systems, Base64 is the right tool. Knowing which problem you have is the whole game.

Encode or decode in three steps

1. Open the Base64 & URL Encoder.
2. Paste your text (or the Base64 string) and pick encode or decode — the output appears instantly.
3. Copy the result. Everything runs inside your browser, so tokens, keys and private strings never leave your machine — worth caring about, since the things people decode most often are credentials.

For binary files rather than text, the Base64 File Encoder converts any file to a Base64 string — with URL-safe and line-wrap options — and back again.

Where you'll meet Base64 in the wild

The JWT case is the one every developer hits eventually. A JWT's header and payload are just Base64url-encoded JSON — decode them and you can read every claim in plain text, which is exactly why you should never put secrets in a JWT payload. The JWT Decoder splits and decodes all three parts in one paste; run the payload through the JSON Formatter if you want it pretty-printed.

Data URIs are the second-most common encounter. Embedding a small icon directly in CSS with Image to Base64 saves an HTTP request — a genuine win for images under roughly 5–10 KB. Above that, the 33% size penalty plus the loss of browser caching makes a normal image file the better choice.

Standard vs URL-safe Base64

If a decode comes out broken, this is usually why. Standard Base64 uses + and /, but both characters carry special meaning in URLs, so the URL-safe variant (RFC 4648) swaps them for - and _ and often drops the = padding entirely. JWTs, OAuth state parameters and many API keys use the URL-safe flavor. A decoder that only speaks standard Base64 will choke on - and _; if you're fixing one by hand, replace - with + and _ with /, then add = until the length is a multiple of 4.

The related classic is confusing Base64 with percent-encoding — %20 and friends are URL encoding, a completely different scheme handled by the same Base64 & URL Encoder. When an entire URL needs dissecting into scheme, host, path and query parameters, the URL Parser does the surgery. Both live in the developer tools collection alongside the rest of the encoding family.

Honest limitations

Base64 always costs about 33% extra size, so it's a transport format, not a storage strategy — don't stuff multi-megabyte files into JSON if a normal file-upload path exists. Encoding very large files in the browser (hundreds of MB) works but is memory-hungry, because the file and its encoded string both live in RAM at once. And decoding binary data into a text box produces screen garbage by design: a decoded PNG is *supposed* to look like noise. Save it as a file instead — that's what the file-oriented tools above are for.

Frequently Asked Questions

Is Base64 secure?

No — it provides zero secrecy. Anyone who sees a Base64 string can decode it instantly, no password required. It protects data from *corruption* in text-only channels, not from *reading*. Treat any Base64-encoded credential exactly like plain text.

Why does my decoded output look like random garbage?

You probably decoded binary data — an image, a PDF, a compressed blob — into a text field. The decode worked; the result just isn't text. Use Base64 to PDF or the Base64 Image Converter to turn the string into an actual viewable, downloadable file.

What do the = signs at the end mean?

Padding. Base64 processes input in 3-byte groups that produce 4 characters each; when the final group has only 1 or 2 bytes, == or = fills the gap. One or two equals signs at the end is normal — equals signs in the *middle* mean the string was truncated or two strings got concatenated.

Why is my Base64 string "invalid" when it looks fine?

Three usual suspects: URL-safe characters (-, _) fed to a strict standard decoder, missing padding, or invisible whitespace copied along with the string — email clients wrap Base64 at 76 characters, and those line breaks come along on copy-paste.

Got a mystery string ending in ==? Paste it into the Base64 & URL Encoder and see what it's been carrying.