UTF-8

English text costs one byte per character, the same as ASCII. Russian or Greek text costs up to two bytes per letter, and Chinese, Japanese and Korean text usually costs three bytes per character. So a string's byte length usually isn't its character count, and a limit in bytes, like a database column or an API field, fills up sooner for some languages. The Character Counter counts visible characters or code points and shows the UTF-16 units and UTF-8 bytes of your text.

Base64 and URL encoding work on these bytes, not on characters. é is the two bytes C3 A9, so Base64 turns it into 4 characters, w6k=, and URL encoding writes it as %C3%A9.

Three design choices explain it. ASCII bytes stay ASCII: RFC 3629 notes that a plain ASCII string is also a valid UTF-8 string, and that ASCII byte values never appear inside a longer character. A parser hunting for /, , or a line feed can keep scanning bytes. UTF-8 is also self-synchronizing, since continuation bytes always start with 10, so a decoder can find the next character after a bad byte. And it has no byte order problem, because it's made of single bytes. A byte order mark (EF BB BF) can still show up at the start of a file, but RFC 3629 notes that its byte order job is useless in UTF-8, so it can only work as a signature.

The result is that about 99% of websites with a known encoding use UTF-8, according to W3Techs. JSON requires it for text exchanged between systems, and the HTML standard requires it for web pages.

Bytes that aren't valid UTF-8, like a lone Latin-1 E9, can't be decoded, and software usually shows the replacement character � (U+FFFD) instead. Decoders also have to refuse overlong forms, like C0 80 for the null character, and the surrogate range U+D800 to U+DFFF.

The other classic failure is reading UTF-8 with the wrong encoding, which gives mojibake like é for é. Save files as UTF-8, and declare it in the charset=utf-8 part of the Content-Type header and with <meta charset="utf-8">.