Those question marks are not a virus or a corrupted file; they are placeholder glyphs, usually U+FFFD (the Unicode replacement character), produced when a program converts or renders text using a character set that has no glyph for the character it is trying to display. The letter i is being replaced on screen, but the stored text has often already been damaged. Fixing it means identifying which layer failed: encoding declaration, font coverage, keyboard layout, autocorrect settings, or clipboard conversion.
The symptom looks trivial and is not. Text encoding is a chain of custody, and a break at any link turns readable characters into question marks that no amount of retyping fixes permanently. The rest of this explainer walks through each link in order, quantifies how often each failure mode occurs, and ends with a diagnostic sequence you can run in minutes. One point up front: in most cases the original character is already gone from the saved file, so restoring it means finding an earlier version, not editing the current one.
The mechanism: encoding, glyphs, and substitution
Every character in a digital document has two separate identities: a numeric code point and a visual glyph. A code point is an abstract number, while a glyph is the shape a font draws for that number. Encoding is the translation layer that maps characters to bytes. Unicode assigns code points to roughly 155,000 characters across 161 scripts as of the current Unicode Standard, and UTF-8 is the dominant encoding on the web, used by well over 95 percent of websites.
A question mark appears when the chain breaks at one of three points. First, a decoder may encounter a byte sequence invalid in the declared encoding and emit U+FFFD, the replacement character, which renders as a question mark or a diamond with a question mark. Second, a font may lack a glyph for a valid code point, and the renderer falls back to a box, a blank, or sometimes a question mark. Third, legacy code pages such as Windows-1252 can display an actual literal question mark where a smart quote or accented letter once sat, because that character never existed in the codepage.
Here is why the letter i specifically shows up in the symptom. In UTF-16, the lowercase i is encoded as two bytes, 0x00 0x69. If those bytes are misread as UTF-8, the leading 0x00 is a valid null character, while 0x69 remains a valid ASCII i. In other words, the letter i is one of the most likely characters to survive a partial conversion, which is why damaged documents often keep islands of i's, l's, and punctuation while everything else turns to question marks. The letter itself is not the problem; it is the visible survivor of a wider wreck.
Plain-language version: the document is not missing the letter i, it is missing the instructions that told the computer what that letter was.
Quantified context: how often this really happens
Mojibake, the general term for garbled text caused by encoding mismatch, is one of the most common data-quality complaints in publishing, data engineering, and legacy document migration. In study of multilingual text corpora, encoding errors routinely affect single-digit percentages of records in otherwise clean datasets, and the rate climbs sharply whenever data passes through a legacy system that assumes a single-byte codepage.
The replacement character itself is a recent invention. U+FFFD was added to Unicode in version 3.0, published in September 1999. Before that point, software had no standard way to mark undecodable bytes and often silently substituted an ordinary question mark, which is why older documents contain literal question marks that cannot be distinguished from intentional punctuation.
The number of affected characters in a single broken file follows a predictable pattern. A pure ASCII character such as a space or a lowercase i survives nearly every misread because ASCII bytes overlap with UTF-8. Accented letters, curly quotes, em dashes, and non-Latin scripts fail almost immediately. This is why a 2,000-word report can contain hundreds of replacement characters while still showing readable English structure around them.
Which layer actually failed
The following table maps observable symptoms to the most likely failure layer. Work down it in order, because a font problem and an encoding problem can produce nearly identical visuals.
| Symptom | Most likely layer | Telltale sign | Typical fix |
|---|---|---|---|
| Question marks appear in every document, including web pages | System font or locale | Menu text is also affected | Change system region and language settings |
| Only smart quotes, accents, or em dashes turn into question marks | Encoding or codepage | ASCII letters remain intact | Reopen with UTF-8 encoding and re-save |
| Question marks appear only on one device | Font fallback | Same file opens correctly elsewhere | Install the missing font family |
| Typing produces question marks in place of letters | Keyboard layout | Wrong characters appear for several keys | Switch input method to the correct layout |
| Question marks appear after copying from a PDF or website | Clipboard conversion | Original source looks fine | Paste as plain text, then reapply formatting |
| One character repeatedly becomes a question mark | Autocorrect or find-and-replace rule | Only that character is affected | Audit autocorrect and replacement rules |
The counterintuitive detail worth pausing on: reinstalling the font rarely fixes mojibake. If the underlying bytes were already replaced with U+FFFD when the file was saved, no font can restore the original character, because the code point is gone. Font changes only help when the code point is valid and the glyph is missing. This distinction is the single most common source of wasted troubleshooting hours, both for individuals and for professional support desks.
Edge cases that break the usual advice
Several scenarios do not fit the standard encoding explanation, and each requires a different response.
Microsoft Word autocorrect "smart quote" substitutions can convert straight apostrophes into curly ones; if the receiving template uses a font or style that lacks the curly glyph, the character can render as a question mark in that document only. PDF export embeds fonts by default, but if a glyph was substituted during authoring, the substitute is baked into the PDF permanently. Encoding of CSV files opened in spreadsheet software is chosen automatically and often guessed wrong, silently producing question marks in accented names. Right-to-left and complex-script documents can show question marks for joined forms when the shaping engine lacks the required font tables. Passwords and serial numbers stored in legacy systems may contain characters the system cannot represent, causing authentication failures that look like typing errors.
Red-flag warning: do not run global find-and-replace operations to swap question marks back to letters. The mapped character is often ambiguous, several different letters may have collapsed into the same placeholder, and replacements can corrupt files beyond recovery. Back up the original before any repair attempt.
Misconceptions worth retiring
The most persistent misconception is that question marks indicate a virus or malware. In practice, encoding and font failures account for the overwhelming majority of cases, and security software is not the right diagnostic tool. The second is that the problem is cosmetic. Mojibake in a database means the original text is unrecoverable without a backup, which has real consequences for legal discovery, medical records, and financial ledgers.
A third misconception concerns the letter i specifically. People often report that "the letter i turned into a question mark," when the truth is that the i survived and neighboring characters did not. Retyping the i will not fix the surrounding text, and the problem will return the moment the file is reopened or re-saved.
Finally, there is a widespread belief that all question marks mean the same failure. They do not. A literal question mark typed by a person, a replacement character inserted by a decoder, and a missing glyph box are three different events with three different fixes, and only careful inspection of the file can tell them apart.
A practical diagnostic and repair sequence
Follow these steps in order. Each step isolates one layer, so you can stop as soon as the symptom disappears.
Open the file in a plain-text editor and inspect the raw characters. If you see U+FFFD or sequences like "’," the failure is at the encoding layer. Check the declared encoding. Reopen the file explicitly with UTF-8, then with the suspected legacy codepage, and compare results. Save only after the text looks correct. Compare the same file on a second device. If it looks correct there, the fault is local to your fonts or settings. Audit autocorrect, find-and-replace, and clipboard conversion rules in the authoring program, especially any rule that targets punctuation or quotes. Verify the font family used by the affected style, and confirm it covers the scripts and symbols in the document. Restore from a backup if replacement characters are already saved into the file, because no in-place edit recovers lost code points.
Threshold guidance for triage: if the damage affects fewer than about 5 percent of characters, manual reconstruction is usually faster than a scripted repair. Above roughly 20 percent, the file is effectively a failed conversion, and restoring the last good version is the only reliable option. Between those thresholds, a scripted repair against a known source encoding is worth attempting, but only on a copy.
Limitations and what this cannot tell you
Encoding repair is reversible only when the original bytes still exist somewhere, such as an older version, a backup, an email attachment, or the source system. Once U+FFFD is written to disk, the information is destroyed, and no tool reconstructs it from the placeholder alone. Font coverage also changes with operating-system and application updates, so a document that rendered correctly last year can begin showing question marks after an update without any change to the file itself.
This article is general educational information about text encoding and document rendering, not a diagnosis or a repair guarantee. For documents with legal, medical, financial, or safety consequences, consult a qualified local professional and preserve the original files before attempting repairs. Nothing here promises that a specific repair will recover your data.