Base64 Encoder and Decoder

Why btoa fails on non-ASCII text

The browser btoa function does not take text. It takes a binary string, meaning every character must have a code point between 0 and 255, the Latin-1 range. The first character above 255 makes it throw rather than return anything. Turkish letters such as ş, ğ, İ and ı all sit outside that range, so an ordinary sentence is enough to break it, and the same applies to Greek, Cyrillic, CJK or any emoji.

1btoa('Kürşad');2// Uncaught InvalidCharacterError:3// String contains an invalid character4 5// 'ü' is inside Latin-1, so this passes but encodes the wrong bytes6btoa('ü');            // single byte 0xFC7// In UTF-8 'ü' is two bytes: 0xC3 0xBC

The second case is the more dangerous one. Because the character falls inside Latin-1 no exception is raised, yet the Base64 carries a single-byte Latin-1 code rather than the UTF-8 bytes. The consumer, which expects UTF-8, sees mojibake, and the root cause is hard to trace precisely because nothing ever threw.

The correct path: bytes first, then Base64

Base64 encodes bytes, not characters. That makes the pipeline inherently two-step: convert the text to UTF-8 bytes explicitly, then convert those bytes to Base64, and reverse the same route when decoding. This tool works exactly that way, so non-ASCII input neither throws nor comes back garbled.

1// Encode: text -> UTF-8 bytes -> Base642function encode(text) {3  const bytes = new TextEncoder().encode(text);4  let binary = '';5  for (const b of bytes) binary += String.fromCharCode(b);6  return btoa(binary);7}8 9// Decode: Base64 -> bytes -> UTF-8 text10function decode(b64) {11  const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));12  return new TextDecoder('utf-8').decode(bytes);13}14 15encode('Kürşad');       // 'S8O8csWfYWQ='16decode('S8O8csWfYWQ='); // 'Kürşad'

Alphabets, padding and whitespace

Base64 has two alphabets in common use. The standard variant (RFC 4648 section 4) uses + and / for values 62 and 63. The URL-safe variant (section 5) substitutes - and _, and usually drops the trailing padding as well. The difference is not cosmetic: a + in a query string decodes back as a space, and a / is read as a path separator.

The = character pads the encoded text to a multiple of four. Since every 3 bytes become 4 characters, a remainder of 1 byte yields two characters plus two pad characters, and a remainder of 2 bytes yields three characters plus one. That is why a length of 1 modulo 4 is impossible: no encoder ever emits a lone trailing character. When you see it, the text was truncated during a copy, and this tool reports that case specifically instead of surfacing an opaque native error.

Pasted input containing newlines is extremely common too. PEM-formatted certificates and keys wrap their Base64 body at 64 characters, and email attachments wrap similarly. That whitespace is formatting, not data, and it must be stripped before decoding. This tool removes all whitespace and line breaks automatically, so you can paste a PEM body straight in.

Base64 is not encryption

This is the most persistent misconception about the format and it is worth correcting directly. Base64 is an encoding, not a cipher. There is no key, no secret component, and the decoding algorithm is entirely public. Base64-ing a password or an API key before dropping it into a config file protects nothing; it only makes the value unreadable at a glance, which is a very different property from confidentiality.

So what is Base64 actually for? Moving binary data through channels that can only carry text. Email bodies, JSON string fields, XML elements, URL components and HTTP headers are the usual cases. The goal is safe transport of bytes, never concealment of their contents.

Decoding binary payloads

Not every Base64 string represents text. Decode a PNG, a protocol buffer or an encrypted blob and you get bytes that are not valid UTF-8. Forcing those bytes through a text decoder fills the screen with U+FFFD replacement characters and tells you nothing. Worse, if you copy that output and re-encode it, the original bytes are gone, because a replacement character is a lossy substitution with no way back.

This tool decodes in strict UTF-8 mode: when the bytes are not valid text it says so rather than substituting silently, and hands back a hexadecimal preview of the leading bytes instead. Knowing that PNG files start with 89 50 4E 47, JPEG files with FF D8 FF, and ZIP archives with 50 4B 03 04 is usually enough to identify what you are actually holding.