You copy a clean Ó, paste it somewhere, and instead of the accent you see an empty box, a question mark or a pair of gibberish symbols. This is frustrating but almost always fixable. This guide names the three common failures and gives the fix for each.
Failure One: The Empty Box
An empty box, sometimes called a tofu, means the character arrived correctly but the font has no glyph to draw it. The code point is fine; the display font simply lacks that letter. This is most common with the rarer accented O forms in fonts with limited coverage.
The fix is to change the font to one with broad Latin coverage. Most system default fonts, and popular web fonts, include the full set of accented vowels. Switching the text or the element to such a font makes the box become the correct character. Nothing about your copied text needs to change.
An empty box is a font problem, not a text problem. The character is intact; you just need a font that knows how to draw it.
Failure Two: The Question Mark
A plain question mark, or a diamond with a question mark inside, usually means the character was forced through an encoding that cannot represent it, and was replaced with a placeholder. Once this substitution happens the original is lost, so the fix has to be applied upstream.
Ensure every stage of the pipeline uses UTF-8: the file encoding, any database column, the connection between application and database, and the page or document that displays the text. A single stage using a legacy encoding is enough to trigger the replacement.
Failure Three: Mojibake
Mojibake is the name for accented characters turning into two or more odd symbols, a telltale sign that UTF-8 text was read as a different encoding. Unlike the question mark case, the data is often still recoverable, because the bytes are intact but misinterpreted.
The cure is to read the text with the correct encoding. If a file shows mojibake, reopen it specifying UTF-8 rather than letting the editor guess. If a web page shows it, correct the charset declaration. Once the reader and the data agree on UTF-8, the accented O reappears.
The CSV Special Case
Spreadsheets importing CSV files are a frequent source of mojibake, because CSV carries no encoding information of its own. Always export and import CSV as UTF-8, and use the import dialog to set the encoding rather than double clicking the file. The spreadsheet guide covers this in detail.
Preventing Problems In The First Place
Almost every accented character problem traces back to inconsistent encoding. Standardise on UTF-8 everywhere, declare it explicitly where you can, and choose fonts with full coverage. Copy your characters from a Unicode aware source such as the finder, which outputs clean precomposed code points, and most of these failures never occur.
In Summary
An accented O breaks in three ways: an empty box means the font lacks the glyph, so change the font; a question mark means a lossy encoding replaced it, so use UTF-8 throughout; and mojibake means UTF-8 was misread, so read it as UTF-8. Consistent encoding and a well covered font prevent nearly all of them.