Why a symbol shows as a box, and what each kind of box means

Four different failures that all look like a box

Tofu is a font problem, not a data problem

This is the reassuring part. If your text shows boxes, the characters are still correct. Copy that text into an application with better font coverage and the symbols appear. Nothing was lost.

It also means the fix belongs in your styling, not in your content. Adding a broad fallback to the end of your font stack means the browser reaches for a font that has the glyph when your preferred font does not. On Windows that is typically the built-in symbol font, on macOS the Apple symbol font, on Android the Noto family and on many Linux systems DejaVu. Naming a couple of those explicitly at the end of the stack is cheap insurance for a page full of symbols.

The variation selector problem, in plain language

Some characters have two legitimate appearances: a monochrome text form and a colourful emoji form. The heavy black heart is the clearest example. Which one you get is decided by an invisible character that can follow it, called a variation selector.

Variation selector 16, code point U+FE0F, requests the emoji presentation. Variation selector 15, U+FE0E, requests the text presentation. Many platforms default one way or the other regardless, which is why a heart pasted from one app arrives red in another and black in a third. If you need one specific appearance, append the selector explicitly and test in the destination.

The same mechanism explains vanishing characters: a variation selector on its own, separated from the character it modified by an unlucky copy, is invisible and does nothing.

Why box-drawing characters look broken even when they render

Box-drawing characters were designed to touch each other edge to edge, which only happens in a monospaced font at the exact cell width they assume. In a proportional font the same characters render fine individually but the lines do not connect, and the result looks like a rendering bug when it is really a font choice.

If you are drawing a frame or a tree in text, set the block in a monospace font and turn off any automatic character substitution. In a browser that means an explicit monospace font stack on the element.

Font fallback is a chain, not a single choice

A browser does not pick one font and give up. It walks your font stack from left to right for each individual character, and it keeps walking past the end of your stack into the system fallback list if nothing you named has a glyph. That per-character behaviour is why a paragraph can render in your chosen font while one symbol inside it quietly comes from somewhere else, at a slightly different weight and width.

It also means a page full of symbols benefits from naming a broad fallback explicitly at the end of the stack rather than leaving it to the system default, which differs by platform and by version. What you gain is not coverage, since the system fallback would have found something anyway, but predictability: you know which font drew the character, so you know why it looks the way it does.

The one place to resist that instinct is the glyph itself on a reference page. Showing a character in the reader own system font is the honest preview, because that is what they will see after they paste it. Forcing a webfont there would make every symbol look correct on our page and tell the reader nothing about their own machine.

Encoding damage, and why re-saving rarely fixes it

Mojibake happens when bytes encoded one way are decoded another. UTF-8 stores anything outside ASCII as two or more bytes, and a decoder that assumes one byte per character renders each of those bytes as a separate character. A degree sign becomes two characters, a long dash becomes three.

The important part is what happens next. If that mangled text is then saved as UTF-8, the wrong characters are now genuinely in the file, correctly encoded. The damage has been baked in, and re-declaring the encoding afterwards does nothing, because there is no longer anything wrong with the encoding.

Sometimes the mapping is reversible with a careful decode and re-encode, but only when nothing was lost along the way, and something usually was: bytes that did not map to a character in the intermediate encoding get replaced rather than preserved. The reliable fix is to go back to a source that was never decoded incorrectly, fix the declaration there, and export again.

A short checklist when something looks wrong

• Confirm the encoding first. Serve and save as UTF-8, and declare it in the document head.
• Paste the text into a different application. If it renders there, it is a font problem, not a data problem.
• Check the code point of the character you actually have, not the one you meant to have. In Word, place the cursor after it and press Alt+X. In Sheets, use the UNICODE function.
• For emoji versus text appearance, look for a variation selector before blaming the font.
• For box drawing and ASCII layouts, set a monospace font before concluding anything else is broken.