Text Encoding Converter
Decodes well-formed UTF-8, UTF-16LE or UTF-16BE bytes into Unicode text, optionally normalises line endings, then writes the same characters in one of those three encodings with an explicit byte-order-mark choice.
A plain-text file up to 25 MB. Binary formats such as Word documents are not text encodings and are refused.
Results are provided as-is, with no warranty of accuracy. The method and its sources are published below so you can check the working.
How it works
What this works out
A text file is bytes plus an agreement about what those bytes mean. UTF-8, UTF-16 little-endian and UTF-16 big-endian can represent the same Unicode characters, but they use different byte sequences. Opening UTF-16 as UTF-8 does not reveal a different font; it decodes the wrong numbers.
This converter makes both agreements visible: how to read the source and how to write the result. Automatic detection is deliberately narrow. It recognises a Unicode byte-order mark, and otherwise uses UTF-8—the web’s safe default—rather than inventing certainty about an unmarked legacy code page.
The method
The WHATWG Encoding Standard’s BOM sniff is a three-row table:
| Leading bytes | Encoding |
|---|---|
EF BB BF | UTF-8 |
FF FE | UTF-16 little-endian |
FE FF | UTF-16 big-endian |
The marker is removed before the text is exposed. When a source encoding is selected manually and its marker says something else, the file is refused. A UTF-16LE marker with a UTF-16BE selection is stronger evidence than either a filename or a guess.
Decoding is fatal: every input byte must belong to a well-formed sequence. The Unicode Consortium permits recovery actions such as replacement characters for illegal input, but the replacement is not the original text. A converter whose promise is lossless should stop and let the owner choose a recovery tool.
Before you read on
An unmarked file contains the byte 80. Can its legacy encoding be identified from that byte alone?
No. An unmarked legacy byte stream does not carry enough information to distinguish all code pages. Auto detection therefore recognises explicit Unicode BOMs and otherwise requires well-formed UTF-8.
A worked example
song.txt is UTF-16LE with the two-byte FF FE marker and contains:
café
🎵
The visible content has 9 Unicode code points: four letters, two CRLF pairs and one musical-note character. UTF-16 stores the note as a surrogate pair—two 16-bit code units—but it remains one code point.
The source is 22 bytes: 2 marker bytes plus 10 UTF-16 code units. Written as
UTF-8 without a marker and with line endings preserved, the result is 13 bytes.
The exact text remains café\r\n🎵\r\n, and the downloaded filename is
song-utf8.txt. The formula test asserts all 22 input bytes, the 13 output
bytes, the character count, both encoding labels and the filename.
Byte order and byte-order marks
UTF-8 operates on eight-bit code units and has the same byte sequence on every processor. Its marker is a signature, not an endian switch. ASCII characters remain their ASCII bytes; other code points take two to four bytes.
UTF-16 works in 16-bit code units. UTF-16LE writes the least-significant byte of each unit first; UTF-16BE writes the most-significant byte first. Characters above U+FFFF use a high and low surrogate, so either byte order takes four bytes for that character. The marker lets a reader distinguish the two serialisations when no external label does.
Line endings are a separate choice
Changing UTF-16LE to UTF-8 does not require changing CRLF to LF. They are different layers: an encoding maps characters to bytes, while a line ending is one or two characters already inside the text. Preserve exactly leaves lone CR, LF and CRLF sequences where they are. The advanced choices first normalise all three and then write consistently as LF or CRLF.
What it does not do
It does not open .docx, PDF, rich text or another container whose visible
words live inside a structured binary format. It also does not detect
Windows-1252, Shift_JIS, GBK or another legacy encoding. Those conversions are
possible when the source label is known, but automatic guessing would weaken
the tool’s core promise that characters do not change silently.
It performs Unicode encoding conversion, not Unicode normalisation. A composed
é and the canonically equivalent sequence e plus combining acute remain in
whichever form the source used.
How it is done
- Inspect the first three bytes for EF BB BF (UTF-8), FF FE (UTF-16LE) or FE FF (UTF-16BE). In automatic mode the marker chooses the decoder; without one, require UTF-8 rather than guessing a legacy code page.
- When the source encoding is selected manually, require any existing marker to agree. Remove the agreed marker, then decode in fatal mode so an illegal byte sequence stops the conversion instead of becoming a silent replacement character.
- Preserve every CR, LF and CRLF sequence by default. Only when selected, normalise all three forms to LF or to CRLF as a separate operation from character encoding.
- Count Unicode code points, treating a valid UTF-16 surrogate pair as one supplementary character. Encode the resulting string as UTF-8 bytes or as two-byte UTF-16 code units in the selected byte order.
- Add the selected target marker—EF BB BF, FF FE or FE FF—only when requested, then offer a separate .txt file. The source file is never changed.
What it assumes
- Auto is intentionally bounded to the three Unicode byte-order marks. An unmarked file defaults to strict UTF-8; Windows-1252, ISO-8859 variants and other legacy code pages cannot be distinguished reliably from bytes alone.
- A byte-order mark at the start is metadata and is consumed before the first text character. A U+FEFF later in the file is content and remains content.
- UTF-8 has no byte-order question; its BOM is only a signature. UTF-16LE and UTF-16BE serialize the same 16-bit code units in opposite byte order.
- Invalid UTF sequences are refused instead of repaired. The input cap is 25 MB, and the code-point and UTF-16 loops yield every 250,000 code units for progress and cancellation.
Common questions
Is the text file uploaded for encoding conversion?
No. The bytes are decoded and re-encoded inside a worker in this browser tab, and the new file is assembled locally. The generated browser test fails if using a real file sends a request away from Tessalor's origin.
What happens when an invalid UTF-8 or UTF-16 sequence is found?
The conversion stops with an explanation. Substituting U+FFFD can be a useful recovery policy, but it changes data; a general converter should not make that choice without being asked.
Does UTF-8 need a byte-order mark?
UTF-8 is byte-oriented, so it has no endian ambiguity. EF BB BF is only an encoding signature and is usually unnecessary in modern web and command-line workflows, though some older software expects it.
Why can one emoji occupy four bytes in both UTF-8 and UTF-16?
A supplementary Unicode character uses a four-byte UTF-8 sequence and a pair of two-byte UTF-16 surrogate code units. It is still one code point, which is why the result count does not call it two characters.
Does changing encoding also change Windows and Unix line endings?
Not by default. Character encoding maps characters to bytes; CRLF and LF are character sequences. The advanced control keeps those jobs separate and preserves the original sequence unless a conversion is selected.