Fix a CSV That Excel Opens Wrongly
- No Sign-up
- 100% Free
- Zero Server Data
A CSV file does not say what alphabet it is written in, so Excel on Windows guesses, and on anything but English it usually guesses wrong. That is why an export full of Thai names opens as a page of accented Latin punctuation. Nothing is broken: the file is fine and Excel is behaving as designed, and three bytes at the front settle the argument. This works out what the file is really written in, shows you the first few rows so you can see it is right, and saves a copy that Excel opens correctly.
1 · The file Excel gets wrong
2 · What it actually says
The first few rows, read with the encoding that was worked out. If this looks right, the download will open right.
Nothing loaded yet.
Frequently asked questions
Why does Excel do this?
A CSV is just text, and text files carry no statement of which alphabet they use. Excel on Windows therefore reads one in the system code page unless the file begins with three specific bytes called a byte-order mark. Most systems export UTF-8 without that mark, so a Thai file arrives correct and opens wrong. The file was never damaged; two programs disagreed about a convention.
What does this actually change?
It adds the three bytes, or converts an older Thai encoding to UTF-8 and then adds them. The text itself is untouched: same rows, same columns, same values. You can open the result in anything, and Excel will now agree with everyone else about what it says.
Is my file uploaded?
No. Your browser reads the bytes, works out the encoding and writes a new file, all in the tab. The site’s security policy sets connect-src ‘none’, so the browser blocks network requests from these pages. Exports that arrive in the wrong alphabet are usually customer lists and order histories, which is exactly the sort of file that should not be handed to a website.
Why not just tell me to use Data, then From Text?
Because that works and nobody remembers it, it is four dialogs deep, and it has to be done again for every file. It also does not help the person you send the file to, who will open it by double-clicking and see the same mess. Fixing the file fixes it for everybody who ever opens it.
What if it cannot work out the encoding?
It says so and does nothing. There are only two possibilities it can confirm: valid UTF-8, which is provable because invalid sequences are rejected outright, and Thai Windows-874, which is confirmed by finding Thai letters. Anything else would be a guess, and a wrong guess rewrites your file into something worse than what you started with.
Does it work on other languages?
The byte-order mark half works for any language: Japanese, Korean, Arabic, Greek, Russian and anything else in UTF-8 have the same problem with Excel and the same fix. The conversion half currently understands Thai Windows-874 only, because that is the legacy encoding this was built for.