Convert TSV Encoding to UTF-8
Excel's Save As → Unicode Text (*.txt) writes a tab-separated file in UTF-16 with a byte-order mark — and then almost nothing on a Unix system can read it, because every ASCII character is followed by a zero byte. Databases reject it, grep finds nothing, Python sees NUL bytes. Drop the file here and get UTF-8 back. Same for the older single-byte code pages that turn é into é or a black diamond.
How to use
- Drop the file. Auto-detect runs immediately and the status line says which encoding it used.
- Check the output for
�characters. The status line counts them — any at all means the source encoding is wrong. - If so, pick the encoding by hand. Work down the list for the language the data is in; the first choice that renders correctly is the right one.
- Download. The result is UTF-8 without a BOM by default, which is what every modern tool wants.
How auto-detect works, and where it fails
Byte-order marks are checked first and are conclusive: FF FE is UTF-16 LE, FE FF is UTF-16 BE, EF BB BF is UTF-8. With no BOM, the file is decoded as UTF-8 in strict mode — UTF-8 has enough structure that invalid byte sequences are detectable — and if that fails it falls back to Windows-1252, the most common single-byte encoding for Western text.
What detection cannot do is distinguish between single-byte code pages, because every byte is valid in all of them. A file that's really ISO-8859-2 Polish will decode as Windows-1252 without error, and just produce wrong letters. There is no way around this from bytes alone; you have to know, or recognise, the language. That's what the manual list is for.
Reading the mojibake to identify the source
The garbled form tells you what happened. é where you expect é means UTF-8 bytes were read as Windows-1252 — the file is already UTF-8 and something downstream is misreading it, so converting here won't help.  at the start of a file is a BOM being read as three Latin-1 characters; see remove a BOM. A single � or black diamond means bytes that are invalid in the encoding used. And text with a NUL byte between every letter, or that shows only the first character of each field, is UTF-16 read as single-byte.
FAQ
Why can't I paste the text in?
Because by the time text is in your clipboard it has already been decoded — correctly or incorrectly — and the original bytes are gone. If the paste looks garbled, that garbling is now the actual content and no re-decoding can recover it. Only the file on disk has the information needed.
What's the command-line equivalent?
iconv -f UTF-16LE -t UTF-8 in.tsv > out.tsv, or iconv -f WINDOWS-1252 -t UTF-8. Add //TRANSLIT to substitute unrepresentable characters instead of failing. file -I f.tsv gives you a rough guess at the source encoding.
Does it convert the delimiter too?
No — encoding and delimiter are separate concerns. UTF-16 files exported by Excel are already tab-separated; you just couldn't read them. If you also need a different delimiter, run the output through change delimiter.
Can it write something other than UTF-8?
No, and deliberately so — there's no good reason to create a new file in a legacy encoding in 2026. If a legacy system demands one, iconv in the other direction is the tool.
How big a file can it handle?
The whole file is held as bytes and again as decoded text, so budget roughly three times the file size in memory. Tens of megabytes is comfortable on a desktop browser.
Privacy
100% client-side. The bytes are decoded by your browser's own TextDecoder; nothing is uploaded. See the privacy policy.