How to fix decomposed accents on a Mac
You can do this with Note My. An accented word can be written two ways that look identical on screen and are not the same text — here is how to tell which one you have, and how to normalise it.
You have two pieces of text that look identical. A name in a data export and the same name in a config file. A key in a JSON document and the same key in the code that reads it. On screen they match, character for character. The comparison still fails, the lookup still misses, the diff still shows a changed line. The two strings are genuinely different text that draws the same picture.
This guide explains what is happening, how to see it in Note My, and how to normalise a file so both forms become one.
Two ways to write the same accented letter
Take é. Unicode gives you two entirely legitimate ways to write it.
- Composed. One code point, U+00E9, latin small letter e with acute. One character, two bytes in UTF-8.
- Decomposed. Two code points: a plain
e(U+0065) followed by U+0301, combining acute accent. The combining mark has no width of its own — it draws on top of the letter before it.
Both render as é, pixel-identical in most fonts. But they are different sequences, so anything comparing code points — a string equality test, a dictionary lookup, a hash, a line diff, a search — treats them as different text. The composed form is what Unicode calls NFC.
The consequences are the ones you have already met. A file is longer than it should be. A search for a word you can see on screen finds nothing. Two files that display identically produce a diff full of changed lines.
Why this turns up so often
Nobody types a combining accent deliberately; decomposed text arrives from somewhere else. Keyboards and input methods generally produce the composed form, while some file-system and export paths produce the decomposed one. Concatenate two files written by two different tools and you can end up with both forms of the same word inside one document — which is why the problem looks intermittent.
No ordinary editing view shows the difference. The text is not corrupt, not mis-decoded and not invisible; it renders exactly as intended. You need a view that names the characters themselves.
The two categories to look for
Our hidden-character scanner offers 21 categories of stray or suspicious character to look for. Three matter here, and none of them is ever changed behind your back: they are reported to you, and nothing in the document moves until you press Apply. Composing an accent alters the text, so the decision stays yours.
| Category | What it matches | Severity |
|---|---|---|
| Non-NFC clusters | Accented text written the long way round, where the composed form of the same letter would be different text. Each finding offers that composed form as its fix. | Warning |
| Combining marks | The accent marks themselves — the ones that carry no width and draw on top of the letter before them. | Info |
| Homoglyph letters | 37 look-alike letters — 22 Cyrillic, 15 Greek — impersonating Latin ones. A different cause of the same symptom. | Info |
Non-NFC clusters is the one that answers the question. Its fix is exact rather than general: each finding proposes the composed form of that exact letter, so French, Vietnamese and Nordic names all come out right, accent for accent. It carries warning severity, so it stands out among the informational rows.
Combining marks is worth ticking alongside it. It shows you every accent in the document, so you can see at a glance how far the problem spreads before you decide anything.
Emoji are safe. A skin-tone, flag or family emoji is never taken apart by a cleanup, so you can run one over a document full of them safely.
Where these findings surface
A decomposed accent is valid, correctly rendered text, so it is something you ask about rather than something that interrupts you. Knowing which part of the window answers which question tells you where to look.
The hidden-characters pill in the status bar is your at-a-glance conscience for damage: characters that are wrong in any context, such as stray control codes and zero-width joiners. A document full of well-formed accents shows the pill as Clean, and that is the truthful answer — nothing in it is broken. Accents are a question of form, and form is the review sheet's speciality.
The in-editor markers — the tint and underline that appear on suspicious characters in the text itself — stay off accented letters on purpose, so a French document reads as prose rather than as a warning label. Reserving the markers for genuine damage keeps them meaningful, and it leaves the accents to the tool that can name them character by character. That tool is one click away, and the rest of this guide walks you through it.
Scan a document for decomposed accents
-
Open the review sheet
Click the wand button in the toolbar and choose Clean ▸ Clean Invisible / Special Characters…. The wand sits beside the document, so the review sheet is two clicks away from any file you have open.
The sheet opens over the document: a scope control reading Selection and Whole Document, a preset pop-up, all 21 categories on the left, and an empty findings table on the right.
-
Enable the two categories
The default preset is Code-safe, 16 categories tuned for source files. For accents, aim narrower still: rather than switching to the Aggressive preset — which arms all 21, including the ones that rewrite smart quotes, dashes and ellipses — tick Non-NFC clusters and Combining marks in the left-hand table yourself.
Ticking any box flips the preset pop-up to Custom. That is expected, and it keeps every other category out of what happens next.
-
Set the scope and scan
Choose Whole Document, then press Scan. It is the default button, so ↩ runs it.
Length is no obstacle here. Our large-file engine takes a multi-megabyte export in its stride, so a data dump is as scannable as a short note — and it all happens on your Mac, with nothing uploaded. The line numbers in the results always match the ones beside your text, even when you scanned only a selection.
-
Read the findings
The right-hand table lists every finding with five columns: Line:Col, Code Point, Category, Action and Risk. The Code Point column ends the argument — it names the actual character in the file, so a combining acute at U+0301 is no longer a guess.
Double-click a row to jump straight to that character in the editor, or select a row and press Show in Editor for the same jump. Either way you can work down the table one finding at a time, moving from a list of code points to the actual word in the actual line and back again, without losing your place in either.
-
Apply the replacements
Press Apply. The button carries a count, so you know how many edits you are authorising before you make them.
Apply changes only the categories you ticked, and only the findings that have a fix to offer. Each accent becomes the composed form of that exact letter, not a blanket rule swept across the file. The whole run is a single undo step named Clean Invisible Characters, so one ⌘Z reverses all of it at once, and the findings list refreshes so you can see what remains.
Combining marks on their own are reported, never replaced — Apply passes straight over them. They are there to tell you where to look. The Non-NFC clusters findings are the ones that actually normalise the text.
Comparing two files that look the same
If the symptom is two files rather than one, compare them. With exactly two tabs open, Quick Compare from the toolbar's Compare menu pairs them immediately; with more, it asks you to click a partner tab. Compare ▸ Compare Files… instead opens a pairing canvas of cards, one per open tab, where you pick one on each side. Either route puts the two documents in front of you side by side.
Our comparison view paints the differences in place in both panes and tints the mismatch down to the individual character — exactly what you need here, since a line whose only difference is a decomposed accent shows the tint inside the word. The inspector reports "N differing lines" and lists them; clicking a row flashes that line in both panes. Parallel scrolling happens only while you hold Shift, and ⎋ leaves compare mode. Neither file is altered by looking.
Troubleshooting
The scan reports nothing but the text still will not match
Check the scope control. If it reads Selection and you have no selection, the sheet tells you plainly; if the selection simply missed the line you care about, widen it. Re-scan with Whole Document and you have covered every line in the file.
If a whole-document scan with both categories ticked really is clean, the accents are not the cause. Look at Homoglyph letters next — a Cyrillic е inside a Latin word is invisible to a reader and fatal to a comparison.
Apply is greyed out, or beeps when clicked
The current findings are all report-only rows — combining marks, homoglyphs and their neighbours, which describe what is there and leave the decision with you. Tick Non-NFC clusters and scan again: those are the findings that carry a proposed composed form, and Apply lights up as soon as one of them lands in the table.
The characters look garbled, not merely different
That is a different fault. Boxes, or a stray  in front of every accent, mean the file was opened as the wrong encoding — the file itself is fine, the reading of it is wrong. Our encoding handling gives you two commands. File ▸ Encoding ▸ Reload with Encoding… opens the same file again as the encoding you choose and leaves what is on disk untouched. File ▸ Encoding ▸ Convert to Encoding… is the opposite: it changes what will be written the next time you save. Decomposed accents, by contrast, render perfectly — that is the whole difficulty, and the review sheet is where you settle them.
Clean AI Copy/Paste Markers left the accents as they were
That is the promise it makes. Our cleanup rules for AI copy-and-paste markers lift out the invisible artefacts and leave your writing exactly as you wrote it — the wording, tone, punctuation, indentation and emoji all survive untouched, which is why you can run it over a finished draft without reading the whole thing again afterwards. Composing an accent rewrites the letters themselves, so that decision comes to you in the review sheet, with a count on the button and a single undo behind it.
You want a full count on a very large document
Go straight to the review sheet. It is the thorough answer at any length: our large-file engine takes the whole document however big it is, and the findings you get are exactly the ones a shorter file would give you — line, column and code point for every cluster in it, gathered in one table you can work through at your own pace.
On a file of that size it pays to work in passes. Scan the whole document once to see the shape of the problem, then double-click your way through the findings that matter to you, and press Apply when you are satisfied. One ⌘Z still reverses the entire run, however many replacements it made, so a big export carries no more risk than a short note.
Taking this across a whole project
One file is rarely the whole story. A name that arrived decomposed in an export usually arrived that way everywhere that export was used, so once you have seen the pattern in a single document it is worth sweeping wider.
Start with Find in Folder. Search a directory for the affected word — the name, the key, the column header — and you get back the files that contain it, without a byte being written to the folder. It reads and reports, so you can point it at a live project or a client's delivery folder with equal confidence. Open the files that matter and run the same two ticks on each.
Then settle both sides of any pair. Our comparison view and our find and replace work on exactly the text that is in the file, which is precisely what makes them trustworthy as diagnostics: when a difference is tinted inside a word, the difference is genuinely there. Normalise both documents and those lines stop appearing as differences, because they have genuinely stopped differing.
Where only part of a file came from the export — a block you pasted in, a table you appended — set the scope to Selection and scan just that. The findings still carry the line numbers that appear beside your text, so you can widen to Whole Document afterwards and pick up exactly where you left off. Every fix stays specific to its own letter: é, ế, å and ñ each come back as themselves, composed accent for accent rather than by a rule swept across the file.
Frequently asked questions
How do I tell whether my file uses composed or decomposed accents?
Run the review sheet with Non-NFC clusters ticked over the whole document. Findings mean non-composed clusters are present, and the Code Point column names the exact characters. No findings for that category means the file is already composed.
Will normalising the accents change how the file looks?
The page looks exactly as it did — the composed and decomposed forms render identically, which is the reason the problem is hard to see in the first place. What changes is the underlying code points, and therefore the file's length and every comparison made against it. Your layout, spacing and wording are all where you left them.
Why does the hidden-characters pill say Clean when accents are decomposed?
The pill is telling you the truth about its own question. It watches for characters that are wrong in any context, and a decomposed accent is valid Unicode that renders exactly as intended, so a document full of them really is clean by that measure. Accents are a question about form, and the review sheet answers that one — precisely, code point by code point.
Can I undo the change if it was not what I wanted?
Yes. The whole Apply run is a single undo step named "Clean Invisible Characters", so one ⌘Z reverses every replacement it made. You do not have to close the sheet first.
Does the file get sent anywhere to be analysed?
Everything in this guide happens on your Mac. Nothing is uploaded, there is no account and no sign-in, and your files never leave the machine — safe enough for a client export or a payroll file.