Skip to content

Base64 Encoder & Decoder

Encodes and decodes Base64 and Base64URL for text or files, handling UTF-8 correctly.

Encodes text or a whole file to Base64, and decodes it back — including data: URIs, and including the URL-safe alphabet a JWT uses. Text goes through UTF-8 first, which is the part the browser’s built-in `btoa` cannot do at all.

🔒 Runs entirely in your browserbase64encodedecode
Mode
Alphabet

The +/ alphabet, as in MIME.

Text or file in

Drop any file

Read in this tab. Nothing is uploaded.

Base64 out

0 characters of Base64.

Text is encoded as UTF-8 before it is Base64ed, which is why 한글 and emoji survive the round trip. The browser’s own btoa cannot do this — it rejects any character above U+00FF outright — so the encoder here is written out rather than borrowed.

How to use it

  1. Type or drop what you have

    The text box takes any text; the drop zone takes any file and encodes it in slices so a large one does not freeze the tab. If you paste something that already looks like Base64 in encode mode, the page offers to switch.

  2. Pick the alphabet

    Base64 is the `+/` alphabet from MIME. Base64URL is the `-_` one, which is what goes into a URL path or a JWT segment. They are not interchangeable — a decoder for one rejects the other.

  3. Decide about padding and wrapping

    The trailing `=` is required by some parsers and forbidden in a JWT. Wrap at 76 is the MIME line length, which matters when the output is going into an email header or a PEM-shaped file and nowhere else.

  4. Take the data URI if that is what you came for

    A dropped file also produces a `data:` URI with its MIME type, and the panel shows how much bigger it is than the file — about a third, which is the number that decides whether inlining is a good idea.

Common questions

Why does Korean text survive here but break elsewhere?

Because the text is encoded to UTF-8 bytes before it is Base64ed. `btoa` in the browser throws on any character above U+00FF, and the common workaround — `unescape(encodeURIComponent(…))` — is what most sites use and quietly gets wrong. The encoder here is written out to avoid both.

Is Base64 encryption?

No, and this matters. It is an encoding — anyone can decode it, including this page. A password or a token in Base64 is in plain sight. If you want secrecy, the text encryption tool on this site does AES-GCM with a passphrase.

The decoded output is empty but there was no error.

Then the bytes decoded fine but are not UTF-8 text — a PNG, a zip, a protobuf. The panel switches to a hex preview and a download button in that case; the text box has nothing to show because there is no text.

How large a file can I encode?

The encoding itself is chunked and will not lock the page, but the result is a single string a third larger than the file and it all lives in memory. Tens of megabytes is where a browser tab starts to complain, and a data: URI that size is not usable anywhere anyway.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.