Character encoding converter

Computers store text as bytes, and a character encoding defines which bytes represent which characters. Most problems with garbled text, known as mojibake, happen when bytes written in one encoding are read in another. This converter shows how a string is represented in UTF-8, UTF-16 and Latin-1 so you can see exactly what is stored and where conversions go wrong.

How to use it

1. Type or paste text.
2. Compare the byte sequences and byte lengths for each encoding.
3. Use the output to debug database columns, API payloads or files that display strange characters.

Example

The word café:

• UTF-8: 63 61 66 C3 A9, 5 bytes. é uses two bytes.
• UTF-16LE: 63 00 61 00 66 00 E9 00, 8 bytes.
• Latin-1 (ISO-8859-1): 63 61 66 E9, 4 bytes.

If the UTF-8 bytes C3 A9 are decoded as Latin-1, they appear as é, which is why you see café on badly configured websites.

Which encoding should I use?

Use UTF-8 everywhere unless a system forces something else. It covers every Unicode character, is ASCII-compatible and is the default for HTML5, JSON and most modern databases. UTF-16 is used internally by JavaScript, Java and Windows. Latin-1 only covers Western European characters.

Debugging checklist

• Declare <meta charset='utf-8'> in HTML and send Content-Type: text/html; charset=utf-8.
• In MySQL use utf8mb4, not the old 3-byte utf8, so emoji can be stored.
• Check how CSV files are opened; Excel often assumes a legacy encoding unless the file has a UTF-8 BOM.