Base64 Encode & Decode

What the Base64 tool does

Base64 writes arbitrary bytes using only 64 safe ASCII characters: every 3 bytes become 4 characters, so the output is about a third larger. Email attachments, data: URIs, the HTTP Basic authentication header and JWT segments all rely on it.

The tool works in both directions. When encoding text it first converts it to UTF-8 bytes, so ş, İ or an emoji give the same result on every system; a selected file is encoded byte for byte. When decoding it turns Base64 into bytes under strict rules, shows them as text if they are valid UTF-8 and as a hex preview otherwise, and lets you download them as a file.

How to use

• Pick a direction: Encode or Decode. When encoding you can choose text or a file as the source.
• Type or paste text; up to 256 KiB the result updates after 150 ms, for larger input press “Convert”.
• Encoding options: standard or URL-safe alphabet, = padding and a line break every 76 characters for MIME. For files you can also get a data: URI.
• When decoding, the alphabet is detected automatically; untick the box to accept only the selected alphabet. Text starting with data:...;base64, is decoded too.
• Copy or download the result: encoding saves a .b64.txt file, decoding saves the raw bytes (types such as PNG, JPEG or PDF are recognised from their signature).

Alphabet, padding and line breaks

RFC 4648 defines two alphabets. The first 62 characters (A–Z, a–z, 0–9) are shared and only the last two differ. The URL-safe alphabet replaces + and /, which have special meaning in URLs and file names.

When the input is not a multiple of 3 bytes the last group is padded with =: == for one remaining byte, = for two. Some formats such as JWT drop the padding; untick the box to get unpadded output. The MIME option inserts a CRLF line break every 76 characters as RFC 2045 requires; data: URI output never uses line breaks or the URL-safe alphabet.

Strict decoding and error messages

• Spaces, tabs and line breaks are skipped and counted, so text that was wrapped or split while copying still decodes.
• A character outside the alphabet, such as ! or a Turkish letter, is an error with its position.
• Mixing +// with -/_ in the same input is reported as a mixed alphabet.
• = may only appear at the end; too little or too much padding, as in Zg=, is an error. Input with no padding at all is decoded with a warning.
• If the number of non-padding characters leaves a remainder of 1 when divided by 4, the text is truncated: no byte sequence produces that length.
• If the unused bits of the last character are not zero, as in Zh==, the text decodes but is flagged as non-canonical.

Example and interpretation

The Example button encodes the Turkish phrase Merhaba Dünya! Çağrı, ışık ve 🚀. Because ü, ç, ğ, ı and ş take two UTF-8 bytes each and the emoji takes four, the 31-character text becomes 41 bytes and 56 Base64 characters:

TWVyaGFiYSBEw7xueWEhIMOHYcSfcsSxLCDEscWfxLFrIHZlIPCfmoA=

To see the alphabet difference, encode two ş letters: the standard output is xZ/Fnw==, the URL-safe unpadded output is xZ_Fnw. The browser's built-in btoa() does not know UTF-8, so it returns x2F5 for Çay and throws on ı; the correct UTF-8 result is w4dheQ==. Decoding //79 yields the bytes ff fe fd, which are not valid UTF-8, so you get a hex preview and a download option instead of text.

Limits and privacy

• Files, text to encode and decoded data are limited to 10 MiB; larger input is rejected, never truncated.
• The hex preview of binary data shows the first 64 KiB; the download always contains every byte.
• Base64 is not encryption; anyone can decode it.
• Text is encoded exactly as typed, without Unicode normalization; input that is not NFC gets a warning because text that looks the same can give different Base64.
• Everything runs in your browser; text and files are not uploaded or stored. The share link never contains file contents or names, and includes your text only if you tick the box.