Base64 encode and decode: UTF-8 text without mojibake

When Base64 is the right tool

You need to put non-ASCII text into a field that only accepts ASCII: an HTTP header, a config value, or a protocol field limited to printable characters. Base64 maps arbitrary bytes onto a safe 64-character alphabet.

You receive a Base64 string and want to know whether it decodes to readable UTF-8 or is just binary noise. A result full of � usually means the underlying bytes are not UTF-8.

You are inspecting the payload of a JWT, a Basic Auth header, or a data URL. Those payloads are Base64 or Base64URL; decode first, then read. Note that JWT uses Base64URL, whose alphabet and padding rules differ slightly.

• Put non-ASCII text into an ASCII-only header or config field
• Check whether a received Base64 string is readable text
• Inspect the payload of a JWT, Basic Auth header, or data URL
• Log short text through a channel that only accepts ASCII

How to get it right

Do not hand a JavaScript string straight to btoa(). btoa() accepts a binary string where every character is in the 0–255 range and throws InvalidCharacterError on anything else. The correct order is TextEncoder to UTF-8 bytes, then btoa() over those bytes; decoding reverses it with atob() and TextDecoder('utf-8').

The output grows by about a third. Base64 turns every 3 bytes into 4 ASCII characters, so the length becomes 4/3 of the input, with = padding when the byte count is not a multiple of 3. In UTF-8, one CJK character is usually 3 bytes and becomes about 4 characters, while one emoji is usually 4 bytes and becomes about 8 characters including padding. That is encoding overhead, not compression.

Whitespace is ignored when decoding, but characters outside the Base64 alphabet cause an error. If the string picked up stray symbols, clean them out first.

Decoding Base64 that is not UTF-8 produces � (U+FFFD). The tool is not broken; the original bytes simply are not valid UTF-8. Images and archives should never be decoded as text in the first place.

For URLs, switch to Base64URL: + becomes -, / becomes _, and trailing = is dropped. In a query string a literal + can be read as a space under form rules, and / can collide with path separators.

Finally, Base64 is not encryption. There is no key, anyone can decode it, and using it to hide a password or token only changes the wrapper. Use AES-GCM when you need confidentiality, and a signature or hash when you need integrity.

• TextEncoder before btoa(); TextDecoder after atob()
• Size grows to about 4/3, with = padding
• Bytes that are not UTF-8 decode to �
• In URLs use Base64URL: - and _, no trailing =

Alternatives and limits

Do not convert binary files with a text tool. Use the base64 command line, base64 -i on macOS, certutil -encode on Windows, or read an ArrayBuffer in code, so the bytes survive exactly.

For confidentiality use WebCrypto AES-GCM; for authentication use HMAC or a public-key signature. Base64 only makes bytes safe to transport as characters and provides no security property.

This tool handles text only: input is interpreted as UTF-8 when encoding and restored as UTF-8 when decoding, so binary bytes cannot survive, and there is no streaming, so very large inputs consume a lot of memory.

• Binary files → command-line base64 or ArrayBuffer
• Confidentiality → AES-GCM
• Integrity → a signature or hash
• Text only; no binary and no streaming