To convert an Excel file to UTF-8, identify the encoding that produced the bytes — Windows-1252 for the standard "CSV (Comma delimited)" export, UTF-16LE for "Unicode Text", or UTF-8 itself when "CSV UTF-8 (Comma delimited)" was used — and re-encode those bytes as UTF-8 without a BOM using a file-based converter. Excel does not expose a single "Save as UTF-8 no BOM" command, and reopening the file in Excel to re-save it can quietly rewrite dates, numbers and leading zeros. A file-based conversion keeps the source bytes untouched and produces a downloadable UTF-8 file in the browser, with no upload, that you can verify in the destination tool before replacing anything.
The reason this matters is that Excel is the most common source of "mojibake" — names like Müller or Łódź rendered as Müller or Åódź in another program. The corruption happens because Excel wrote Windows-1252 bytes that a downstream tool later interpreted as if they were Latin-1 or UTF-8. Re-encoding the original Windows-1252 bytes through a standards-defined Windows-1252 decoder turns byte 0x80 (the euro sign) into the three UTF-8 bytes E2 82 AC, which every modern tool reads back as €. The same logic applies to curly quotation marks, em-dashes and the Windows-1252 range from 0x80 through 0x9F that ISO-8859-1 leaves undefined.
Why Excel files need UTF-8 conversion
Excel's CSV export predates UTF-8's widespread adoption, so its default text encoding is Windows-1252 — a Western European code page that covers most accented Latin letters but not Greek, Cyrillic, Hebrew, Arabic, CJK ideographs or emoji. UTF-8 is the encoding of the open web, of every modern database import script and of nearly every data pipeline, so the moment an Excel CSV leaves your machine, downstream code expects UTF-8. If the file still contains Windows-1252 bytes, those bytes either get re-interpreted (producing mojibake) or fail validation outright.
Excel offers a confusing mix of "Save as" options that all sound like UTF-8 but produce different byte layouts:
| Excel "Save As" choice | Byte encoding produced | Byte order mark | Field separator |
|---|---|---|---|
| CSV (Comma delimited) | Windows-1252 | None | Comma |
| CSV UTF-8 (Comma delimited) | UTF-8 | EF BB BF (BOM present) | Comma |
| Unicode Text | UTF-16LE | FF FE | Tab |
| Text (Tab delimited) | Windows-1252 | None | Tab |
"CSV UTF-8" is the only Excel option that writes UTF-8, and it always adds a BOM. Many scripts — Python's open(..., encoding='utf-8'), awk, shell while read loops and most Linux tooling — reject or mis-handle a leading BOM, so a BOM-free file is usually what you actually want.
Choose the real source encoding for an Excel export
Before converting, confirm what the file actually contains. Two reliable methods work without guessing from appearance:
- Check Excel's save dialog. The exact "Save as type" you chose tells you the source encoding. "CSV" alone equals Windows-1252. "CSV UTF-8" equals UTF-8 with a BOM. "Unicode Text" equals UTF-16LE with a BOM. "Text (Tab delimited)" equals Windows-1252.
- Read the first bytes in a hex viewer. Bytes FF FE at offset 0 mean UTF-16LE. Bytes FE FF mean UTF-16BE. Bytes EF BB BF mean UTF-8 with a BOM. Anything else without a BOM is almost always Windows-1252 for a Western Excel export.
The converter does not detect encodings. It will fail loudly rather than produce a plausible-looking but corrupted file if you pick the wrong source. This is intentional: the same byte sequence can be valid under multiple legacy encodings while representing different characters, so an automatic guess can corrupt names, punctuation or currency symbols while the rest of the file looks normal. Fatal validation applies to UTF-8 mode in particular — invalid continuation bytes, truncated sequences and forbidden encodings cause a clear failure rather than replacement characters.
Convert an Excel-exported file to UTF-8
- Identify the source encoding from the table above (Windows-1252 for plain CSV, UTF-8 for CSV UTF-8, UTF-16LE for Unicode Text).
- Open the UTF-8 Converter and select that source encoding from the list.
- Click the file picker and choose your Excel-exported file. The tool refuses anything over 10 MB before reading it, so a too-large file produces a clear message instead of a frozen tab.
- Convert and read the preview carefully. Scroll to a row that contains a known non-ASCII character — a customer name with an accent, a currency column with €, a header with é or ñ — and confirm it renders correctly before downloading.
- Download the result. The filename gains a -utf8 suffix and the bytes are emitted as BOM-free UTF-8 with a plain-text media type. Keep the original Excel file untouched until you have verified the new file in its destination application.
The same workflow applies to tab-delimited text exports: pick Windows-1252 as the source and the tab characters pass through decoding unchanged. The tool does not translate line endings; if your Excel file uses CRLF and the destination expects LF, decode then re-encode with an explicit line-ending tool.
What changes after conversion
Different encodings use different byte lengths for the same characters, so the file size almost always changes. ASCII letters stay one byte either way, but accented characters expand:
| Character | Source bytes (Windows-1252) | Output bytes (UTF-8) | Size change |
|---|---|---|---|
| é (U+00E9) | 1 byte (0xE9) | 2 bytes (C3 A9) | +1 byte per occurrence |
| € (U+20AC) | 1 byte (0x80) | 3 bytes (E2 82 AC) | +2 bytes per occurrence |
| 中 (U+4E2D) | Not representable | 3 bytes (E4 B8 AD) | New in UTF-8 |
| 🚚 (U+1F69A) | Not representable | 4 bytes (F0 9F 9A 9A) | New in UTF-8 |
A 5 MB Windows-1252 CSV of European names typically grows by roughly 10–20% after a correct UTF-8 conversion because every accented letter adds a byte; a pure ASCII export stays exactly the same size. The converter reports source and output byte counts so the expansion is visible and you can confirm it matches what the encoding change should produce. Different counts are expected and do not by themselves indicate data loss.
Verify the UTF-8 output before replacing the original
Download is not the last step. Open the new UTF-8 file in the application that will actually consume it — a Python script, a database loader, a web form, a Notepad window — and confirm three things:
- Non-ASCII sample characters render the way they did in Excel, including accented names, currency symbols and any curly punctuation.
- The first three bytes are not EF BB BF if your downstream tool rejects BOMs. The converter emits BOM-free UTF-8 by design.
- Column count, row count and field separators are unchanged. Decoding and re-encoding preserve byte-for-byte what the source encoding could already represent; they never merge or split fields.
If the preview shows replacement diamonds (�), the chosen source encoding is wrong for at least part of the file. Switch the source and reconvert rather than trying to "fix" the broken output. Changing the file or the source encoding cancels the visible result and invalidates the prior download URL, so always grab a fresh download after a re-conversion.
When this approach does not fit
The browser-based converter holds the whole file in memory and stops at 10 MB, so database dumps, multi-gigabyte log exports and large Excel workbooks saved as Unicode Text need a streaming conversion utility with explicit source and destination encodings — iconv on Linux, Get-Content -Encoding plus Out-File -Encoding utf8 in PowerShell, or Python's open(..., encoding='cp1252') followed by open(..., encoding='utf-8', newline=''). The converter also cannot repair files that mix encodings within a single column — once bytes from two encodings sit next to each other, no single decoder will produce the right text for both, and the tool will fail with a fatal decoding error rather than silently exporting replacement characters. Unpaired or malformed UTF-16 surrogates are rejected for the same reason: silent replacement diamonds while claiming a successful conversion is exactly the failure mode the standards-based fatal decoding is designed to prevent.
For files that are already valid UTF-8 but include a leading BOM, a file-based guide to removing the UTF-8 BOM walks through the same conversion with UTF-8 selected as the source encoding; the standards-based UTF-8 decoder consumes the BOM and the encoder emits a clean file.
For a deeper look, see Convert Hex to Text PowerShell: Safe UTF-8 Methods.