To fix garbled text when opening a UTF-8 file in Excel, convert the source file into a clean UTF-8 byte stream with an explicit source encoding selected, then import that file through Excel's data-import dialog rather than double-clicking it. Excel's automatic file-detection logic typically falls back to the Windows system locale, which on most Western installations is Windows-1252, whenever no byte-order mark is present; that is why a perfectly valid UTF-8 file containing accented names, currency symbols, or smart punctuation can appear as mojibake the moment you open it. The fix has two parts: confirm what encoding actually produced the file in its source application, then run those bytes through a converter that uses fatal validation rather than silent replacement. A tool such as the UTF-8 Converter lets you pick UTF-16LE, UTF-16BE, Windows-1252, or validate existing UTF-8, preview the decoded characters, and export a downloadable UTF-8 file without a BOM. After downloading, open Excel through Data → From Text/CSV and choose UTF-8 in the import wizard so Excel reads the bytes you intended, not the ones it guessed.
Why Excel Mangles UTF-8 Files by Default
Excel's "open file" path has never been a faithful UTF-8 reader. When you double-click a .csv or .txt file, Excel looks for a few signature bytes to make an educated guess about the encoding, and when it cannot find a signature, it falls back to the code page associated with the current user's regional settings. On a US or Western European Windows install, that fallback is Windows-1252. The bytes that represent "é" in UTF-8 (0xC3 0xA9) are not valid single-byte Windows-1252 characters in those positions, so Excel renders them as "é" or another mojibake string. The same applies to the euro sign, curly quotation marks, em-dashes, and non-Latin scripts.
Even when you choose Save As → CSV UTF-8 in Excel, the resulting file is not a plain UTF-8 CSV — Excel writes a UTF-8 byte-order mark (the bytes EF BB BF) at the start. That BOM is what helps Excel round-trip its own files, but it also breaks a wide range of downstream tools that interpret the BOM as printable garbage or strip it inconsistently. If your goal is interoperability with other systems, you usually want UTF-8 without the BOM, which is exactly what a dedicated converter produces.
Identify the File's Real Source Encoding
Before you touch the bytes, find out which encoding actually wrote the file. The source application usually knows: a Java service writes UTF-8 by default, an older Windows Notepad dialog writes UTF-16LE, many legacy CRM exports write Windows-1252, and a handful of network or mainframe pipelines use UTF-16BE. If you cannot ask the source application, look for these signatures in the first few bytes of the file.
| Encoding | Signature bytes | Where you typically see it |
|---|---|---|
| UTF-8 (no BOM) | None — ASCII-only first bytes look identical to Windows-1252 | Modern Linux tools, Python, Node.js, Java, web APIs |
| UTF-8 (with BOM) | EF BB BF at offset 0 | Excel "CSV UTF-8" export, some Windows utilities |
| UTF-16LE | FF FE at offset 0 (or FE FF if a BOM is present) | Older Windows Notepad, some legacy Windows exports |
| UTF-16BE | FE FF at offset 0 | Some Java network protocols, big-endian mainframes |
| Windows-1252 | None — single-byte encoding | Legacy Western European apps, older databases, ISO-8859-1 mislabels |
The presence or absence of a BOM is decisive for UTF-16, but UTF-8 and Windows-1252 both look like ordinary single-byte text at the start of a file. That is why a tool that "auto-detects" encoding can confidently pick the wrong one — the same byte sequence can be valid Windows-1252 and the start of a multi-byte UTF-8 character, while representing entirely different characters. The only reliable answer is metadata from the producing system.
Convert the File to UTF-8 Step by Step
Once you know the source encoding, run the file through a converter that decodes with the encoding you selected and re-encodes with the standards-defined UTF-8 encoder. The UTF-8 Converter handles this in your browser, so the source bytes never leave your machine, and the conversion follows the rules in the WHATWG Encoding Standard for fatal decoding.
- Open the UTF-8 Converter in your browser.
- Choose the source encoding that actually produced the file: UTF-8, UTF-16LE, UTF-16BE, or Windows-1252.
- Select the text file you want to convert. The tool checks the size before reading, so anything over 10 MB is rejected up front rather than freezing the page.
- Click Convert. The selected source bytes are decoded with the WHATWG label and fatal error handling, so an invalid continuation byte, truncated sequence, or unpaired UTF-16 surrogate produces a clear failure rather than a row of replacement diamonds.
- Inspect the preview. Look at representative lines that contain accented names, punctuation, currency symbols, or non-ASCII text — these are the characters most likely to expose a wrong encoding choice.
- Note the source and output byte counts shown on the page. Different counts are expected: a Windows-1252 euro byte 0x80 becomes the three UTF-8 bytes E2 82 AC, and most multi-byte UTF-8 sequences are longer than their single-byte legacy counterparts.
- Click Download to save a plain-text UTF-8 file whose name ends in -utf8 and whose bytes contain no BOM.
If the preview shows the wrong characters, change the source encoding and convert again — the page revokes the previous object URL as soon as you pick a new file or encoding, so you cannot accidentally download a stale result.
Import the UTF-8 File Into Excel the Right Way
The conversion alone is not enough; you also have to tell Excel to read the result as UTF-8. Skip the double-click path entirely.
- In Excel, choose Data → From Text/CSV (or Get Data → From File → From Text/CSV in newer versions).
- Pick the converted -utf8 file you just downloaded.
- In the import preview, open the File Origin dropdown and choose 65001: Unicode (UTF-8).
- Confirm that the preview pane shows the expected characters — for instance, "Müller", "€500", and any non-ASCII names render correctly.
- Load the data into a worksheet, save the workbook as .xlsx, and only then delete the original source file.
This path works equally well if your goal is to produce a UTF-8 text file from a workbook. Save the worksheet as CSV, identify the resulting file's encoding (Excel's own CSV UTF-8 export is UTF-8 with BOM, so use the converter with the UTF-8 source option to strip the BOM and re-emit a clean file), and continue from there.
Common Mistakes That Still Produce Mojibake
Even with the right tool, a few pitfalls can leave you staring at "é" again.
- Selecting UTF-8 for a file that was actually written as UTF-16LE. UTF-16LE reads the file two bytes at a time in little-endian order; reading those same bytes as UTF-8 produces invalid continuation sequences, and the fatal decoder will reject the file outright rather than corrupt it.
- Confusing Windows-1252 with ISO-8859-1. Bytes 0x80 through 0x9F map to printable punctuation and symbols in Windows-1252 (including the euro sign and curly quotes) but are undefined in ISO-8859-1. A file labelled ISO-8859-1 is almost always Windows-1252 in practice.
- Picking the wrong UTF-16 byte order. The letters in a file can become nonsense if endian order is reversed even though every pair of bytes still looks readable. Choose little-endian for formats that store the low byte first and big-endian for formats that store the high byte first; the converter recognises and removes a matching BOM either way.
- Replacing the original file before verifying the imported worksheet. Keep the source until names, punctuation, currency symbols, and a few non-ASCII rows have all been spot-checked.
Limits of This Workflow and What to Use Instead
The browser-based converter works on a file up to 10 MB because it operates on an in-memory buffer. Database dumps, multi-gigabyte logs, or directory-wide batches fall outside that scope and need a streaming utility with explicit source and destination encodings: iconv on Linux and macOS, PowerShell's Get-Content combined with Set-Content and an explicit -Encoding parameter, or a Python script that opens the file with the chosen encoding and writes with encoding="utf-8". Each of those tools takes the same two arguments you already chose in the converter: a real source encoding, and UTF-8 as the destination.
If your file contains mixed encodings on different lines, no single converter can repair it reliably — that is a separate normalisation step that belongs upstream in the producing system. For everything else in the 10 MB range, the combination of explicit source selection, fatal UTF-8 validation, and BOM-free output gives Excel a file it can finally read the way you wrote it.