Why Your CSV Shows ??? or Empty Boxes Instead of Letters

Updated July 2026 · By the CSVUndo team · 6 min read

The quick answer: there are three different problems hiding behind “my letters turned into symbols,” and they don’t all have the same ending. A literal question mark (?) means the accent was destroyed when the file was saved — that is permanent, and no tool can bring it back. A black diamond with a question mark inside (�, the replacement character) means a program couldn’t decode some bytes when it opened the file. An empty box usually means your data is completely fine and only the font is missing a glyph. This guide shows you how to tell which one you have in about ten seconds, fix the ones that are fixable, and stop it happening again. Importantly, this is not the same as é-style mojibake, which is usually fully reversible.

Which symptom do you have?

Start here, because the three symptoms have completely different outcomes. Look closely at the broken characters and match them against the table below — the difference between a plain ? and a diamond � is the difference between “gone forever” and “maybe fixable,” so it is worth zooming in.

A plain ? is the ordinary ASCII question mark (byte 0x3F), the same one you type. The replacement character � is a distinct symbol — a diamond or box with a question mark inside it — and it never appears on your keyboard. If your text is peppered with recognisable Latin sequences like é, è or “ instead, you have mojibake, not this problem, and it belongs in the é instead of é guide.

Literal question marks: the permanent one

If you see plain ? characters where accents should be, the letters are almost certainly already gone. This happens at save time, not read time. When a program writes out text containing é, ñ or ü but the chosen output encoding cannot represent them — classically saving UTF-8 content as plain ASCII, or as a legacy ANSI code page like Windows-1252 that lacks that glyph — it substitutes a question mark for each character it can’t store and carries on. Once the file is written that way, the byte on disk is literally 0x3F, and nothing in the damaged file distinguishes a ? that replaced é from one that replaced ñ.

This is the honest, unwelcome headline of this page: no tool can recover a literal ?, ours included. The only real fix is to go back to the system that produced the CSV and export again as UTF-8. Confirm the loss first by opening that original source export: if the accents are intact there, you just had a bad export step; if they are already question marks at the source, the damage happened further upstream. Either way, the repair lives at the source, not in the broken file.

The black diamond � (U+FFFD)

The replacement character � (Unicode code point U+FFFD) is inserted while a program reads a file, and that timing is what gives you a chance. When an application decodes bytes under one encoding but the bytes were actually written in another — so a byte sequence is invalid under the assumed encoding — it drops in U+FFFD to mark “I couldn’t interpret this” and keeps going. Crucially, if you have only opened the file and not re-saved it, the real bytes are usually still sitting on disk untouched. Close the file without saving, then reopen it with the correct encoding (see the next section) and the accents often reappear intact.

The trap is saving while U+FFFD is on screen. The moment you save, the program writes those replacement characters into the file as real data, overwriting whatever bytes were there — and now the original is unrecoverable, exactly like the literal ? case. So the rule is simple: if you see diamonds, do not save — reopen with the right encoding first. The replacement character is defined by the Unicode Standard for exactly this “unknown or unrepresentable” role; read more at unicode.org.

Empty boxes: usually nothing is wrong

An empty rectangle — sometimes nicknamed “tofu” — almost always means your data is perfectly fine and only the font is at fault. The bytes decode correctly to a real character; the font your viewer happens to be using simply has no glyph to draw it, so it shows a placeholder box. This is a display issue, not a data issue, and no letters have been lost.

You can prove it to yourself: copy the box and paste it somewhere that uses a different font, or open the CSV in a plain text editor such as VS Code or Notepad++. If the character shows up correctly there, nothing was ever wrong with the file — you were just looking at it through a font that couldn’t draw that symbol. Because there is no data loss, you can safely ignore it or change viewers.

Fixing and re-saving as UTF-8

For the recoverable cases, the fix is to open the original file — the one from before any lossy save — with the correct encoding, then save it back out as UTF-8. Do this before editing anything, so you never overwrite the good bytes.

1. In Excel: go to Data → From Text/CSV, pick your file, and in the preview set File Origin to “65001: Unicode (UTF-8)”. Check the accents look right, then click Load.
2. In a text editor (VS Code or Notepad++): reopen the file with the correct encoding — in VS Code use “Reopen with Encoding,” in Notepad++ use the Encoding menu — confirm the letters are right, then save as UTF-8.
3. When saving from Excel, always choose “CSV UTF-8 (Comma delimited)” so the next program that opens the file reads the accents correctly.

Microsoft documents the import and export dialogs in its guide to importing and exporting text and CSV files. One related gotcha worth knowing: Excel sometimes needs a byte-order mark to recognise UTF-8 on a plain double-click, which we cover in the UTF-8 BOM and Excel guide. And if what you actually have is é rather than ? or a diamond, head to the fully-reversible mojibake guide instead. For everything else, the guides index lists the common CSV rescue jobs.

Frequently asked questions

Sources: Microsoft’s import or export text and CSV files documentation covers the File Origin and CSV UTF-8 options. The replacement character U+FFFD is defined by the Unicode Standard.