Why Your CSV Opens as Chinese Characters or Squares (It's UTF-16, Not Damage)

Last updated: August 2026 · By the CSVUndo team · 7 min read

The quick answer: a CSV that opens as a wall of Chinese-looking characters — or as squares and stray gaps wedged between every letter — is almost always a UTF-16 file being read with the wrong encoding, and nothing in it is corrupted. Every byte of your data is still on disk; the strange screen is just those bytes being grouped into characters by the wrong rule. Read the file as what it actually is, save a UTF-8 copy, and the original text comes back character for character. This guide shows how the illusion works, how to prove the file is UTF-16 in seconds, the tab-delimiter surprise hiding inside Excel’s UTF-16 exports, and how to convert to UTF-8 without introducing new problems.

Why does my CSV open as Chinese characters?

Because pairs of one-byte characters are being read as single two-byte characters. A text file is only bytes; the encoding is the rule for grouping those bytes back into letters. Legacy encodings like Windows-1252 use one byte per character. UTF-16 — the encoding Windows uses internally — uses two. When a program applies the two-byte rule to text that was written one byte per character, every pair of your letters fuses into a single 16-bit value, and the result is drawn as whatever character owns that value in Unicode.

Roughly one in three of the 65,536 possible 16-bit values falls inside the CJK Unified Ideographs block (U+4E00–U+9FFF, 20,992 code points), which is why mis-paired Latin text comes out looking Chinese far more often than it comes out looking like anything else.

A concrete example: the letters Na are the bytes 4E 61. Read little-endian as one UTF-16 unit, they become U+614E — the ideograph 慎. The same fusion is behind the famous Windows Notepad bug where the plain-ASCII sentence “Bush hid the facts” reopened as 畂桳栠摩琠敨映捡獴: Notepad’s encoding sniffer guessed UTF-16 for a one-byte file. Byte order can pull the same trick on a real UTF-16 file — the letter N stored little-endian is 4E 00, and read big-endian that is U+4E00, 一, literally the first CJK ideograph in Unicode. In every variant the ideographs are an artefact of grouping, not content: your file does not contain Chinese, and no tool needs to “remove” anything from it.

Why does my CSV show squares or gaps between every letter?

This is the same mismatch running in the other direction: a genuine UTF-16 file being read one byte at a time. In UTF-16, ordinary Latin characters each carry a companion zero byte — Name is stored as 4E 00 61 00 6D 00 65 00. An 8-bit reader takes each byte separately, so between every real letter it finds a NUL character (byte 00), which has no visible glyph. Depending on the viewer, those NULs render as empty squares, vertical bars of “tofu”, or invisible gaps that make the text read like N a m e , C i t y.

Spreadsheets and importers show their own versions of the symptom: every row lands in a single column, headers are “not recognised”, or a strict loader rejects the file for containing “invalid characters” — the NULs again. None of this is data loss. The letters are all present in the file, exactly where they should be, interleaved with zero bytes that the reader was never supposed to see individually. Decode the file as UTF-16 and the squares vanish because they were never characters in the first place.

Where do UTF-16 CSV files come from?

Almost always from Windows software, because Windows itself speaks UTF-16 internally. The usual suspects:

• Excel’s “Unicode Text (*.txt)” export. This is the big one. Excel offers no UTF-16 CSV, so people who need “Unicode” pick this format, get a UTF-16 LE file with a byte-order mark — and, crucially, tab separators rather than commas — then rename it to .csv. More on that trap below.
• Windows PowerShell redirection. Up until PowerShell 7 switched the default to UTF-8, the > operator and Out-File wrote UTF-16 LE. A script that worked for years quietly produces UTF-16 “CSVs” on the older shell.
• SQL Server’s bcp utility in wide mode (-w), plus assorted Windows admin and registry export tools that write “Unicode” text.

The file extension tells you nothing here: .csv describes the intended layout, not the encoding, and a UTF-16 file renamed to .csv is still UTF-16. That is also why the same file can look fine in one program and broken in another — an editor that honours the byte-order mark decodes it correctly, while a tool that assumes UTF-8 or ANSI shows squares. The file did not change between the two programs; only the guess did.

How do I check whether my CSV is really UTF-16?

Look at the first two bytes. Nearly every UTF-16 file made on Windows starts with a byte-order mark (BOM): FF FE for little-endian or FE FF for big-endian. Excel, Notepad and PowerShell all write one. A text editor will read it for you — Notepad++ shows the encoding in its status bar (it names UTF-16 “UCS-2 LE BOM”), and VS Code shows “UTF-16 LE” as a clickable label in the bottom-right corner.

Or skip the editor: drop the file on our CSV encoding checker. It reads the file’s actual bytes on your device, reports UTF-8, UTF-8 with BOM, UTF-16 LE/BE or legacy ANSI in plain English, and points to the matching fix. The file never leaves your browser — the check is a local byte inspection, not an upload.

One honest limit: the checker identifies UTF-16 by its byte-order mark. A BOM-less UTF-16 file — rare, but some database exports produce one — is not valid UTF-8 either, so it can be reported as ANSI instead. If the verdict says ANSI but the file shows the tell-tale gaps-between-letters pattern, open it in a hex-capable editor: a zero byte after every letter settles it as UTF-16.

How do I convert a UTF-16 CSV to UTF-8 without breaking it?

First, know the tab trap: if the file came from Excel’s Unicode export, it has two quirks, and fixing only one leaves it broken. “Unicode Text (*.txt)” is tab-delimited, so after a perfect encoding conversion you own a well-formed UTF-8 TSV. An importer that expects commas will still stack everything into one column. Deal with the encoding and the delimiter in the same pass — our TSV to CSV guide covers the delimiter side in depth.

Four ways to do the conversion, from fastest to most manual:

1. In your browser: drop the file on the CSV ⇆ TSV converter. The byte-order mark tells it to decode UTF-16 correctly, it detects the tab delimiter on its own, and you pick comma output and download a UTF-8 copy — encoding and delimiter fixed together, entirely on your device. Tick “Add UTF-8 BOM” only if the file is going back to Excel; see why Excel wants the BOM. Files are handled up to 60 MB, with a warning above 12 MB because the whole conversion runs in one pass in the tab.
2. Notepad++: open the file — the status bar confirms UCS-2 LE BOM — then Encoding → Convert to UTF-8 and save. Note this changes only the encoding; tabs stay tabs.
3. VS Code: the BOM is detected automatically, so the text already displays correctly. Click the encoding label in the status bar, choose Save with Encoding → UTF-8. Again, the delimiter is untouched.
4. Excel: import via Data → From Text/CSV (the BOM sets the File Origin automatically; pick “1200: Unicode” if not), click Load, then save as “CSV UTF-8 (Comma delimited)”. This fixes encoding and delimiter at once — but a round-trip through Excel can alter the data, which is exactly the caveat of the next section. The full route is in saving an Excel file as CSV UTF-8.

Whichever path you take, verify afterwards: reopen the result, confirm accented names read correctly, and confirm the columns split on commas. If an editor was already showing readable text before you converted, you were reading the true content — the conversion just makes every other program agree. For the general text-editor procedure, see changing a CSV’s encoding to UTF-8.

What can the conversion not bring back?

The encoding change itself is lossless. UTF-8 can represent every character UTF-16 can, so converting between them is a re-labelling of the same text, not a repair — accents, symbols and genuine CJK content all survive intact. That is the good news, and it is worth repeating: the Chinese-characters symptom is one of the few CSV disasters where nothing was actually lost.

The caveats live upstream of the encoding. If the data passed through Excel at any point, Excel’s own limits may have already rewritten it: numbers longer than 15 significant digits had their trailing digits replaced with zeros at save time, and digits Excel truncated that way and saved are unrecoverable — no encoding conversion, ours included, can restore them. Stripped leading zeros are the same story with a happier ending, since a known code width lets you re-pad them.

And when you inspect the recovered file, resist judging values on shape alone. A cell reading 2E5 looks like scientific-notation damage, but it can be a perfectly real part number — expanding it to 200000 on a hunch rewrites correct customer data. Treat a value as damaged only when the pattern and the context both say so, which is exactly why our tools flag candidates instead of silently rewriting them. Finally, if the converted file shows é where accents belong, that is a different, usually reversible problem — see why é turns into é — and literal ? marks belong to their own, less forgiving guide. The guides index maps every other symptom.

Frequently asked questions

Sources: the CJK Unified Ideographs block and the UTF-16 encoding form are defined by the Unicode Standard. Microsoft documents Excel’s text formats, including Unicode Text, in its guide to importing and exporting text and CSV files.