The two ways to represent é
Unicode gives you two legitimate ways to encode the same visible character. Precomposed (NFC): é as a single code point, U+00E9. Decomposed (NFD): é as two code points stacked together — plain e (U+0065) followed by a combining acute accent (U+0301). Rendered on screen, both look exactly like é. Compared byte-by-byte, they are not the same value at all.
Both are valid, both are common, and different systems produce different ones by default. macOS's filesystem has historically favored NFD for filenames. Many web forms, databases, and copy sources produce NFC. When your search term comes from one convention and your stored data comes from the other, an exact-match search finds nothing.
How to tell which one you're dealing with
You generally can't tell by looking — that's the entire problem. A practical diagnostic: copy the suspect character and check its byte length in our Unicode inspector. NFC é is 2 bytes; NFD é is 3 bytes. If a search fails only for accented entries and succeeds for the same words without accents, normalization mismatch is the first thing to check. For more on byte encoding mechanics, read our UTF-8 vs UTF-16 vs ASCII guide.
The fix, at three levels
If you control the code: normalize both the stored data and the incoming query to the same form — NFC is the common target — before comparing. JavaScript's String.prototype.normalize('NFC'), Python's unicodedata.normalize('NFC', text), and equivalents in Java, PHP, and Ruby all do this. Normalizing only one side just moves the mismatch.
If you're just typing the search query: try retyping the accent using a different input method than whatever produced the original data — see Mac special characters or our Windows Alt codes.
If you manage a database: check your column collation. A collation doing accent-insensitive, normalization-aware comparison (common modern defaults in Postgres and MySQL) papers over this without touching application code.
Why this matters beyond search boxes
The same NFC/NFD mismatch breaks string equality checks in code, deduplication logic, and URL slugs generated from names. Anywhere text is compared rather than just displayed, an unnormalized accented character is a latent bug waiting for the first José, Renée, or François to hit it. For the broader picture, check our Unicode explained overview.