CSV Encoding & BOM
Fix the encoding problems that make a CSV look broken: accented characters turning into é, Excel refusing to show Cyrillic or Polish text, or a stray byte-order mark glued to the first column name. Drop a file to have its encoding detected, then write it back out as whatever your target tool actually wants.
How to fix a CSV's encoding
- Drop the file in. With auto-detect the status line tells you what it was read as and whether a BOM was present.
- If the text still looks wrong, pick the real source encoding by hand —
Windows-1252for most Western exports,Windows-1251for Cyrillic,ISO-8859-2for Central European. - If characters appear as
é,’, orü, tick repair mojibake — that's UTF-8 that was previously read as Latin-1, and it's reversible. - Choose the output encoding and download. The file is written as real bytes, so the BOM is genuinely there or genuinely absent.
Which output should I pick?
- UTF-8 with BOM — for double-clicking into Excel on Windows. Without the BOM, Excel assumes the local codepage and mangles accents.
- UTF-8, no BOM — for everything else: databases, Python,
psql \copy, Git. A BOM here shows up as junk in the first column name. - UTF-16 LE with BOM — what old Excel versions and some Windows tools export natively.
- Windows-1252 / Latin-1 — only for legacy systems that can't take UTF-8. Characters outside the range are written as
?, and the status line counts how many were lost.
The sep= trick
Excel picks its CSV delimiter from your Windows regional settings, which is why a comma file can open as one long column in a German or French locale. A first line reading sep=, overrides that. It's an Excel-specific hint — leave it off for any other consumer, since most parsers will treat it as a data row.
FAQ
What is a BOM and why does it break things?
The byte-order mark is three invisible bytes (EF BB BF) at the start of a file. Excel uses it to detect UTF-8; most other tools don't expect it and expose it as part of the first field name, so id silently becomes id and lookups fail.
Can I recover text that's already mojibake?
Usually yes, if it went through exactly one wrong decode — that's what the repair option undoes. Text that was saved lossily (real characters already replaced by ?) can't be recovered.
Does pasting text work the same as dropping a file?
Pasted text is already Unicode, so there's no source encoding to detect — the read-as setting only applies to dropped files. The output encoding still applies to your download.
My file has a BOM and the wrong line endings.
Fix the endings with Line endings, or run Repair CSV, which strips the BOM, normalises newlines, and fixes ragged rows in one pass.
Privacy
100% client-side. No upload. See the privacy policy.