Base64 Encoder and Decoder

Base64 is not encryption

This needs saying first because the mistake is so common and so costly. Base64 is an encoding, not a cipher. Anyone can decode it instantly, with no key and no effort — this page does it as you type.

Storing a password "encoded in Base64" provides no protection whatsoever. Nor does putting an API key in a Base64 string in client-side JavaScript, or sending credentials Base64-encoded over plain HTTP. HTTP Basic authentication does exactly that, which is why it is only acceptable over TLS — the TLS provides the security, not the encoding.

What Base64 is actually for is safe transport of binary data through text-only channels. Email attachments, data URIs in CSS, binary fields in JSON, X.509 certificates in PEM files. It converts arbitrary bytes into 64 printable ASCII characters that survive systems that would otherwise mangle them. That is a real and useful job, and it has nothing to do with secrecy.

The UTF-8 problem

JavaScript's built-in btoa() throws an error on any character outside Latin-1, which means café works and 日本語 does not. A surprising number of online Base64 tools are thin wrappers around btoa() and either fail or silently corrupt non-Latin text.

The correct approach is to encode the string to UTF-8 bytes first, then Base64 those bytes. This tool does that, so Arabic, Chinese, Japanese, Cyrillic, emoji and accented Latin all round trip exactly. If you have ever encoded text somewhere, decoded it elsewhere and got question marks or mojibake back, this is almost certainly why.

The same applies in reverse when decoding: the bytes have to be interpreted as UTF-8 rather than as Latin-1. A quick way to test any Base64 tool is to encode and decode the string Zoë — 日本語 🎉 and see whether it comes back intact.

Standard versus URL-safe, and padding

Standard Base64 uses + and / as its final two characters. Both have meaning in URLs — + can be interpreted as a space, / is a path separator — so Base64 in a query string or path segment breaks in ways that are irritating to debug.

The URL-safe variant, defined in RFC 4648 section 5, substitutes - and _. It is what JWTs use, which is why a JWT can sit in a URL or an Authorization header without escaping. If you are putting Base64 anywhere near a URL, use the URL-safe variant.

Padding is the other variable. Standard Base64 pads with = to a multiple of four characters. Some contexts strip it — JWTs do — because it carries no information and = also needs escaping in URLs. Decoders should accept input with or without padding, and this one does. If a decoder rejects your input, missing padding is the first thing to check.

How to use the Base64 Encoder & Decoder

1. Paste text or Base64

   The tool detects which you have pasted and switches mode automatically. You can override it with the toggle.

2. Or upload a file

   Any file type. Choose raw Base64 or a complete data URI with the MIME type prefix, which is what you need for embedding in CSS or HTML.

3. Choose standard or URL-safe

   Use URL-safe if the result is going into a URL, a query parameter or an HTTP header.

4. Copy the result

   Remember that Base64 is roughly a third larger than the original data — that matters for data URIs embedded in stylesheets.

Frequently asked questions