Symbols Not Showing in the Browser? Encoding and Font Fixes

Mojibake looks like real but wrong letters: é where é should be,€ where € should be, ’ where a curly apostrophe should be. The character is intact in the file and is being decoded with the wrong table.

Missing glyphs look like empty rectangles, sometimes with four tiny hex digits inside. Designers call these tofu. The character decoded perfectly; the font simply has no picture for it.

Question marks in diamonds mean the character was already lost before it reached the browser, usually by passing through a system that could not represent it. That one is covered incopied symbols turning into question marks.

The declaration has to arrive within the first kilobyte of the document, so put it first in the head:

<meta charset="utf-8">

That alone fixes most cases. Three things can still override it:

• An HTTP header that disagrees. AContent-Type: text/html; charset=iso-8859-1 header wins over the meta tag. Fix it at the server or CDN.
• The file is not actually UTF-8. Re-save it as UTF-8 without BOM in your editor. A declaration does not convert anything.
• The database connection is wrong. Text that is correct in the database but wrong on the page usually means the connection charset is latin1 while the column is utf8mb4.

The full walkthrough for text pasted out of Word is onfixing Word to website encoding, andUTF-8 versus UTF-16 versus ASCIIexplains why the byte sequences look the way they do.

Encoding changes will not help here. The browser needs a font that contains the character, and it will walk your font stack from left to right until it finds one.

font-family: Inter, "Segoe UI Symbol", "Apple Symbols",
             "Noto Sans Symbols 2", sans-serif;

The characters most often missing are mathematical operators, arrows, dingbats and the rarer currency signs. Emoji have their own dedicated system fonts and rarely fail this way.

Two habits prevent most of it. Test on a machine that does not have your design fonts installed, since your own machine will silently substitute and hide the problem. And subset web fonts carefully: an over-aggressive Latin-only subset will strip exactly the symbols you were trying to display.

More detail is inwhen a font shows boxes instead of characters.

Paste these into the page you are debugging. If the first row renders and the second does not, it is a font problem. If neither renders correctly, it is encoding.

Row one, common Latin-1:éñü£©

Row two, beyond Latin-1:∑≠⌘₹☕

To identify exactly which code point you are dealing with, paste it into theunicode inspector. It will also reveal invisible characters that may have travelled along with your text.

Both the HTML and the font file are cached, and a CDN may hold the old response for longer than your browser does. After every change, re-test in a private window, and purge the CDN before concluding that a fix did not work. A surprising share of second and third attempts are made against a cached copy of the first.