FileKiln

Base64 Encoder / Decoder

Encode text to Base64 or decode Base64 back to text, with correct UTF-8 handling for emoji and non-Latin scripts. Runs in your browser.

Ready when you arebase64 ⇄ text
Runs on your computer. Nothing gets uploaded.

Your stuff stays yours. The conversion happens in this page's JavaScript. Nothing you paste here leaves your machine, and the tool keeps working with the network unplugged.

Plain btoa() in a browser corrupts anything outside Latin-1, which is why many online encoders mangle emoji and accented characters. This tool encodes through UTF-8 bytes first, so any text round-trips correctly. Decoding is strict: invalid Base64 or bytes that are not valid UTF-8 raise an error instead of producing garbage.

How to use the Base64 encoder and decoder

  1. Paste text or a Base64 string into the Input box.
  2. To turn text into Base64, click Encode → Base64. To turn Base64 back into readable text, click Decode → Text. Both write to the Output box, and the input stays where it is.
  3. If decoding fails, the output box is emptied and an error appears under the buttons. The problems section below explains the usual messages.
  4. Click Copy result to copy the output, or Clear to empty both boxes.

How Base64 turns bytes into text

Base64 represents binary data using 64 characters that survive almost any text channel: A to Z, a to z, 0 to 9, +, and /. The encoder takes the input three bytes at a time. Three bytes are 24 bits, which split into four 6-bit groups, and each group picks one character from the alphabet. That is why Base64 output is always about a third larger than the data it holds: every 3 bytes become 4 characters.

When the data does not divide evenly into threes, the last group is padded. One leftover byte produces two characters plus ==, and two leftover bytes produce three characters plus =. So H encodes to SA==, Hi to SGk=, and Hi! to SGkh with no padding at all. The decoder here accepts input with the padding left off, so SGk decodes to Hi as well.

Base64 works on bytes, not characters, so text has to become bytes first. This tool always uses UTF-8 in both directions. A plain English letter is one byte, while an accented letter takes two bytes and most emoji take four.

A worked example

Type café ☕ (with one space) into the Input box and click Encode → Base64:

Y2Fmw6kg4piV

Here is where those 12 characters come from. The text is five characters but nine UTF-8 bytes:

CharactersUTF-8 bytes (hex)Base64
c a f63 61 66Y2Fm
é and the spaceC3 A9 20w6kg
☕E2 98 954piV

Nine bytes divide evenly into three groups, so there is no = padding. Paste Y2Fmw6kg4piV back in and click Decode → Text to get café ☕ again.

The encoder encodes exactly what is in the box, including invisible characters. Hi gives SGk=, but Hi followed by a newline gives SGkK. If your result does not match the one another program produced, check for a trailing line break or space in the input. The output is also one unbroken line; the tool does not wrap it at 76 characters the way email attachments are wrapped.

Common problems and how to fix them

"The string to be decoded is not correctly encoded"

This is the browser's decoder rejecting the input (the wording differs slightly between browsers). Common causes:

  • URL-safe Base64. The Base64url variant, used in JWTs and many web APIs, replaces + with - and / with _. This decoder only accepts the standard alphabet. Replace every - with + and every _ with /, then decode. For tokens, the JWT decoder handles this for you.
  • A data URL prefix. Strings like data:image/png;base64,iVBOR... include a header. Delete everything up to and including the comma.
  • Two strings joined together. Padding is only allowed at the very end, so SGk=SGk= fails. Decode each part separately.
  • A truncated copy. If a character count leaves one character over a multiple of four, the string cannot be valid. Copy it again in full.

"The encoded data was not valid" (a UTF-8 error)

The Base64 itself was fine, but the bytes inside are not UTF-8 text. There are two usual reasons. The data may be binary: an image, a PDF, or compressed data. A string starting with iVBORw0KGgo, for example, is a PNG file. This tool decodes to text only, so it refuses rather than showing broken characters. The other reason is text that was encoded from a legacy character set such as Windows-1252, where é is the single byte E9. Y2Fm6Q== is café in that encoding and fails here for that reason.

The output looks like Base64 again

The data was encoded twice somewhere along the way. Click Decode → Text a second time after moving the output back into the input box.

Related tasks

If the text is going into a URL rather than a data field, you probably want the URL encoder instead. To check whether two pieces of text are identical before encoding, compare their hashes with the SHA-256 hash generator.

Questions this tool gets asked

Why do other tools garble emoji and accents?

They call the browser's btoa() directly, which only accepts Latin-1. This tool converts text to UTF-8 bytes before encoding, so every Unicode character survives the round trip.

Is Base64 encryption?

No. Base64 is an encoding, not encryption; anyone can decode it. Use it for transport and embedding, never for secrecy.

Whitespace in my Base64 input breaks other decoders. Here?

Whitespace and line breaks are stripped before decoding, so Base64 copied from emails or PEM-style blocks decodes fine.

Related tools