Fix broken accents

Recognize garbled text without assuming every accent is wrong

Mojibake is text that looks wrong because the original bytes were read using a different character encoding. An accented word such as café can appear as café; curly punctuation can become a short sequence of unexpected symbols. It often affects several similar characters at once while ordinary ASCII letters remain readable. These are clues, not proof that any individual sequence should be replaced.

Try a small excerpt that contains one expected word and some punctuation. If a place name is familiar, use it as a reference to check whether the result makes sense. Save the original before repairing it. The editor proposes a reversal of a common UTF-8 decoding mistake, not a translation or a spelling correction. It cannot infer a name from an unknown symbol with no original information left.

A missing glyph is different from a decoding mistake. If the same text displays normally in one font or application but as boxes in another, the receiving environment may not have the necessary glyphs. Copy one affected character into the character inspector if you need to see what the text actually contains. Change the encoding only when the evidence points to a character conversion problem.

Test one layer on a known phrase

Paste the following example into Original. The odd sequences are intentional in this example: they represent a common misreading of accented letters and curly punctuation.

Meet at the café.
    It’s a short walk.

The likely repair is café in the first line and It’s in the second. The sentence itself should not be rewritten. Compare a word containing no accents before and after to check that ordinary text is unchanged. If the result introduces a new problem, keep the original and investigate the encoding of the source instead of accepting every proposed change.

For real data, include a line that already looks right in the test. That is especially important in a mixed document assembled from several sources. One source may be garbled while another contains the literal characters you intended. A text example describing mojibake can deliberately contain the same sequences this tool is designed to repair. It would be wrong to “correct” the example without preserving its original subject.

Check whether the source fits the UTF-8 assumption

This editor looks for plausible UTF-8 byte sequences represented by characters from a common mistaken decoding. It checks a candidate before proposing a replacement. The result is not a universal detector for every historical or regional encoding. A document saved in another encoding, damaged during export or mixed from incompatible sources can require a different recovery process.

If you can access the original file, try to open or re-export it with the correct character encoding rather than relying on a repaired clipboard copy. Find the earliest point in the workflow where the words look wrong. For example, check a product name in the source system, then the downloaded file, then the destination where you pasted it. The first differing step is more informative than guessing from the final rendering alone.

Use a test record with an accent, a curly apostrophe and a word made entirely of basic Latin letters. This makes it easier to see whether only certain values are affected. Keep an example of the expected string next to the broken export. If the workflow can be corrected upstream, you avoid having to repair every new copy by hand.

Distinguish a recoverable sequence from a lost character

A replacement symbol such as � can mean that a previous step already discarded the original bytes. An ordinary question mark may be a real punctuation mark or a substitute inserted during export. In either case, the visible character alone does not contain enough information to recreate the original. Replacing every question mark with an accent would invent data and could damage valid sentences.

Ask for a clean re-export, compare an earlier version or consult the source of truth for affected names or identifiers. If recovery requires manual correction, record which fields were confirmed and which remain uncertain. Do not use a visually plausible spelling as evidence that a customer's name or identifier was restored correctly.

Check whether the problem affects a stable field such as an ID as well as a display name. A change in an ID can break matching even if its repaired form looks more readable. For a small comparison, paste the known original and candidate in the text diff checker and inspect character changes. If a name comes from an authoritative source, verify it there before treating the repair as final.

Run a second pass only when you can verify a second layer

Sometimes text went through more than one bad conversion. A first pass can reveal a shorter garbled sequence rather than the intended word. Copy that intermediate value into a new input or use Use result as input, then examine the effect of one additional pass on just a sample. Do not repeatedly run repairs on an entire file until the text stops changing; a sequence that looks repairable can be valid in its context.

Compare the intermediate and final results with a known word or phrase. If the second pass changes a section that already looked correct, restore it from the earlier copy. In a long mixed document, handle just the affected blocks and keep the original. This prevents a real quotation, technical example or spelling convention from changing along with genuinely corrupted text.

Write down which steps you tried and the expected form of one representative record. This helps another person tell whether a future import has the same problem or a different one. Use the guide to encoding and invisible characters to distinguish a second mistaken decoding from a normalization or spacing issue.

Do not confuse decoding mistakes with entities or normalization

A sequence such as é is an HTML character reference, not necessarily corrupted text. Use the HTML entity decoder if the destination needs the visible character rather than that markup representation. A value with percent escapes in a link belongs to a URL context; use the URL component decoder on the value if that is what the source uses. These are intentional representations, not mistakes to correct by changing the character encoding.

Likewise, two correctly rendered accents can differ internally without either being garbled. Unicode normalization can make canonically equivalent sequences consistent. It will not ordinarily turn café into café because that requires a different operation. Use the smallest operation that addresses the issue you actually observed.

When the visible result is correct but a search or import still fails, check exact characters and whitespace. A nonbreaking space, a zero-width mark or a changed apostrophe can cause a comparison mismatch even after a decoding problem has been fixed. Inspect an affected pair and change the specific feature that caused the failure. Keep intentional punctuation and language-specific marks rather than treating all non-ASCII text as suspect.

Verify names, punctuation and record boundaries before reuse

Read the repaired section in its actual destination. Check one name, one ordinary word, one punctuation mark and one line at the end of the pasted selection. If the input came from a table, make sure the export still has the intended separators and quoted fields. An encoding repair can make the words readable without solving a separate issue with the structure of the file.

Before sharing a support case, reproduce the problem with invented data that has the same kinds of characters. Report the source application, the first step where the text differs and one expected result. That is more actionable than sending an entire corrupted document. Retain the original export until a clean version has been accepted by the receiving application.

Distinguish a repaired text excerpt from a repaired file

Copying repaired text into a new file may be sufficient for a small note. For a structured export, also check the delimiter, line endings and encoding that the receiving importer expects. The browser preview repairs a string; it does not rewrite the original file header or recover missing records. When the problem began in a recurring export, document how to produce the corrected file rather than relying on a paste correction every time. A verified two-line sample is useful, but it should be followed by a controlled import of the actual file format.