Why other Base64 tools break on emoji
btoa(), the browser's own Base64 function, only understands Latin-1: every character has to be a single byte from 0 to 255. Handed an emoji, or almost the whole of Chinese, Japanese or Korean, it throws. Handed an accented letter it does something worse than throw: café encodes to Y2Fm6Q==, four Latin-1 bytes, no error, and wrong for everything downstream that reads UTF-8. This tool runs the string through TextEncoder first, so only UTF-8 bytes reach btoa().
Base64 is not encryption
Anyone can decode Base64 back to the original bytes with no key, because encoding never required one. Using it to "hide" a password in a config file or an API request is obfuscation at best. Its job is carrying binary data through formats that only understand text: an image in CSS, a JWT's header and payload, a MIME attachment.
Common problems
- "Invalid character" is usually the wrong alphabet: a plus or slash while URL-safe is on, a dash or underscore while it is off. The two alphabets are treated as distinct.
- Incomplete Base64: it comes in groups of 4, and a paste one character short of a group cannot be restored by padding. Reported rather than guessed.
- "Not valid UTF-8 text" means the bytes decoded but hold a file, not a string. Download them instead of reading them as characters.
- Line breaks in a pasted token, common once Base64 has been wrapped at 76 columns for MIME or a PEM file, are ignored rather than treated as invalid.
Frequently asked questions
Why is the result a third larger than the input?
Because the encoding packs 3 bytes into 4 characters. That is a 33.3% penalty every time, by construction, and no implementation avoids it. It is the price of moving binary through something that only accepts text.
Does encoding change the file at all?
Not a byte. Base64 is a reversible text representation of the exact input, so decoding it returns a file identical to the original, metadata included. It is a transport format, not a transformation.
Why does my decode fail on a padding error?
A Base64 string's length modulo 4 can be 0, 2 or 3, never 1: a single leftover digit carries 6 bits, and no sequence of bytes ends on exactly that. A length one past a multiple of 4 means characters were lost in transit, usually to a line wrap or a truncated copy.
Is my input uploaded?
No. Text and files are both encoded in this tab, and nothing is sent anywhere. Worth knowing, since the strings people decode here are very often tokens and credentials.
What is the difference between standard and URL-safe Base64?
The same alphabet and bit-packing, with + swapped for -, / for _, and the = padding dropped (RFC 4648 §5). +, / and = each already mean something in a URL, which is why a JWT's header and payload use it.