Text Encoding Converter

What a text encoding is, and why several exist

Computers store text as numbers. An encoding is the rulebook that maps characters to bytes and back. Unicode assigns every character a number (a code point) — the letter A is U+0041, the euro sign is U+20AC, an emoji has its own — but a code point still has to be written as actual bytes, and that's where encodings differ. UTF-8 is the dominant choice on the web and the sane default for almost everything: it's ASCII-compatible (the first 128 characters are a single byte, identical to plain ASCII) and uses one to four bytes per character as needed.

Older and narrower encodings still turn up. Latin-1 (ISO-8859-1) and Windows-1252 use a single byte per character, which covers Western European languages but nothing beyond — no Greek, Cyrillic, CJK or emoji. UTF-16 uses two or four bytes per character and is common inside Windows and Java internals. Converting between them re-encodes the same characters into a different byte representation; the text doesn't change, the bytes do.

Mojibake — why text turns into garbled symbols

That mess where an accented word becomes a string of garbage characters, or a document is suddenly full of question-mark boxes, has a precise cause: the bytes were written with one encoding and read with another. It's called mojibake. The classic case is UTF-8 text interpreted as Latin-1 — a single accented character that UTF-8 stored as two bytes gets shown as two separate garbage characters, because Latin-1 reads each byte as its own character.

The fix is to read the bytes with the encoding they were actually written in. The bytes themselves are usually intact and recoverable — nothing is lost, it's purely a decoding mismatch — so converting with the correct source encoding restores the original text. The hard part is knowing which encoding produced the file, since a raw byte stream rarely says; try interpreting it as UTF-8 first and the original almost always comes back.

The BOM, and other practical gotchas

• A BOM (byte order mark) is an optional few bytes at the very start of a file that signal the encoding and, for UTF-16, the byte order. It helps some programs auto-detect encoding — but a UTF-8 BOM can break others (it shows up as stray characters at the top of a file, or upsets tools that expect a bare ASCII first line, like some shell scripts and CSV parsers).
• UTF-16 has two byte orders (little-endian and big-endian); read the wrong one and every character is scrambled. This is the original reason the BOM exists.
• ASCII is a subset of UTF-8 — pure ASCII text is already valid UTF-8 with no conversion needed. The trouble only starts at the first non-ASCII character.
• When you save a file other tools will read, prefer UTF-8 without a BOM unless something specifically requires otherwise. For encoding text for URLs or transport, see URL Encode and Base64.
• Encoding is not encryption — converting to UTF-16 or Base64 changes how text is represented, not whether it's readable. Anyone can decode it; don't mistake an encoding for a way to hide data.