Pasted Symbol Turns Into a Question Mark? Here Is Why

When text is converted into a character set that cannot represent a character, the converter has to put something in its place. Most choose a literal question mark. That substitution is one-way: the original code point is not stored anywhere alongside it.

So the goal is never to repair the pasted text. It is to find the narrow step, widen it, and re-enter the character from the source.

If you are seeing empty boxes rather than question marks, the character is still intact and the fix is a font — seesymbols not showing in the browserinstead.

Work through these in order and stop at the first one that fails.

1. Plain text editor. Paste into Notepad or TextEdit in plain text mode. If it fails here, the copy itself was bad — recopy from a different source.
2. The input field, before saving. Paste and look at the field. If it turns into a question mark immediately, client-side code is sanitising it.
3. After saving and reloading. Correct in the field but wrong after reload means the database or the connection to it is the narrow step.
4. In the export or the email. Correct in the application but wrong in a CSV, PDF or outgoing message means the export encoder is at fault.

This is the most common cause in real systems, and MySQL is the usual setting. A column declared utf8 in MySQL is not full UTF-8 — it stores at most three bytes per character, which covers accented Latin letters and most symbols but excludes emoji and some less common scripts. Those are exactly the characters that turn into question marks.

The fix is utf8mb4 for the column, the table and the connection. All three matter: a utf8mb4 column reached over a latin1 connection still loses characters, and that combination produces the confusing case where the same value looks fine in one client and broken in another.

In SQL Server, the equivalent is NVARCHAR rather than VARCHAR, and string literals need an N prefix to survive.

Excel is a frequent offender in both directions. Saving as CSV writes the file in the system's legacy code page and silently replaces anything outside it; saving asCSV UTF-8 preserves the characters.

On opening, a plain CSV with no byte order mark is assumed to be the legacy code page, which is how correctly exported files still display incorrectly. Use Data, From Text/CSV and set the file origin to 65001: Unicode (UTF-8) rather than double-clicking the file.

Related symbol handling inside spreadsheets is covered inExcel special characters.

Outgoing mail declares its own charset per message part. A sending library configured for ASCII or ISO-8859-1 will substitute anything outside that range, and subject lines are particularly fragile because they use a separate encoding mechanism from the body.

If the body survives but the subject does not, that is the reason, and the setting to change is the header encoding rather than the message charset.

Sometimes the narrow step belongs to someone else. Two options survive almost anything.

Use an HTML entity where the destination renders HTML: €for €, ° for °, € for the numeric form. TheHTML entities guidehas the full table.

Use an ASCII substitute where it does not: EUR for €, deg for °, (c) for ©. Not elegant, but it survives every legacy pipeline ever built.

These three sit at different width tiers, so pasting all of them tells you exactly how narrow the failing step is. If only the third fails, you have a three-byte limit such as MySQL utf8. If the second fails too, you are down to a single-byte code page.

étwo bytes,€three bytes,𝄞four bytes.

The unicode inspectorwill confirm what actually arrived at the other end.