Your CSV opens in Excel full of — or —. Here is what broke, and a tool that fixes it.

Vendor names come out as á. Every apostrophe is ’. A dash becomes —. The file was almost certainly fine — it is the handoff between the program that wrote it and the program that opened it that went wrong. Drop the file below and this page will tell you which of the three failures you have, and hand back a corrected copy.

Just tell me what ’ means

Paste any garbled text and this will work backwards to the character it started as.

The three failures, and how to tell them apart

Almost every instance of this is one of three things. They look identical on screen and have different fixes, which is why guessing wastes an afternoon.

1. The file is correct; Excel guessed wrong

This is the common one. The file is valid UTF-8, but it carries no byte-order mark — three bytes at the very start, EF BB BF, that say "read me as UTF-8." Without them Excel does not sniff the content. It falls back to a legacy single-byte encoding based on your system, and every non-English character shatters into two or three garbage ones. Nothing is lost; it is being read wrong. Adding the mark fixes it and changes nothing else.

The tell: the same file looks perfect in Google Sheets, Numbers, or a text editor, and only Excel is wrong.

2. The text was already corrupted before it was saved

Here the damage is baked into the bytes: something read UTF-8 as Windows-1252, then saved the result back out as UTF-8. Now the file genuinely contains the character â followed by € followed by ™. No amount of opening it correctly will help, because there is nothing left to read correctly. It has to be reversed, which is what the tool above does — it re-encodes each character back to the single byte it came from and re-reads the result as UTF-8.

The tell: it looks wrong everywhere, including in a plain text editor.

3. The file is in a legacy encoding and was never UTF-8

Older systems — and plenty of current accounting exports — still write Windows-1252 or Mac Roman. That is not broken, it is just old. It has to be converted rather than repaired, and the conversion is only safe if you know which legacy encoding it was. The tool distinguishes Windows-1252 from Mac Roman by testing both and keeping the one that produces valid text.

The fingerprints

The garbage itself tells you which encoding did the damage. This is the fastest diagnosis there is — if you see the middle column, you are looking at a Windows-1252 misread.

How to stop it happening again

If you are writing the file: save as UTF-8 with the byte-order mark. In Python that is one character in the encoding name — encoding="utf-8-sig" instead of encoding="utf-8". Most languages have an equivalent. It is the cheapest fix in the chain and it is the one that gets skipped, because the developer opens the file in a text editor, sees it is fine, and ships it.

If you are only receiving the file: do not double-click it. In Excel use Data → From Text/CSV and set the File Origin to UTF-8. Double-clicking bypasses the import dialog entirely and takes the fallback guess, which is the whole problem.

What this tool does not do

It changes encoding and nothing else. Delimiters, quoting, line endings, column order and every byte of your actual data pass through untouched — it cannot reshape your file, which is deliberate. It also will not repair text that has been through the mangle twice in different encodings; if the output still looks wrong, run it again and if the second pass changes nothing, the original bytes are genuinely gone and the file needs re-exporting at source.