Windows-1252 Windows-1252 (CP-1252, Western European) Windows Code Pages Flagship
Microsoft's Western European code page — near-identical to Latin-1, but with curly quotes, dashes, and € filled into the gap Latin-1 leaves empty.
What it is
Windows-1252 is Microsoft's Western European single-byte code page — the default ANSI encoding on Western-locale Windows for decades, and still extremely common in files exported from Windows tools (Excel, older Notepad, legacy Office formats) as of 2026. It's built on the same foundation as ISO-8859-1 but fills the 0x80–0x9F range — which Latin-1 leaves as unused control codes — with actually useful printable characters: curly ("smart") quotes, em/en dashes, the euro sign, trademark symbol, and a few others.
This overlap-but-not-quite-identical relationship with Latin-1 is the single most common cause of "why did my quotes turn into weird symbols" bugs when moving text between Windows tools and web/Unix systems.
Byte structure
| Byte range | Content |
|---|---|
| 0x00–0x7F | Identical to ASCII |
| 0x80–0x9F | Printable characters: curly quotes “ ” ‘ ’, en/em dash – —, ellipsis …, €, ™, and others (this is the range where it diverges from Latin-1) |
| 0xA0–0xFF | Identical to ISO-8859-1 — accented Western European letters and symbols |
Notably, a handful of positions in the 0x80–0x9F range (specifically 0x81, 0x8D, 0x8F, 0x90, 0x9D) remain unassigned even in Windows-1252 itself — those five slots are undefined in both encodings.
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
Curly quotes become “ / †, em dash becomes â€" |
UTF-8-encoded smart quotes/dashes were decoded as Windows-1252 (or the reverse) — a very common bug when copy-pasting from Word/Outlook into plain-text or web contexts |
€ symbol shows as € correctly in one place but garbled elsewhere |
One system is treating the text as Windows-1252 (which has €), another as pure ISO-8859-1 (which doesn't) — mismatched assumptions across the pipeline |
| Text pasted from Word looks fine until exported/emailed | Word defaults to inserting Windows-1252-style smart quotes and dashes even in documents nominally saved as UTF-8, and downstream systems that don't handle the conversion correctly mangle those specific characters |
| CSV exported from Excel shows garbled accented characters when opened elsewhere | Excel historically exports CSVs in Windows-1252 (or the OS locale's ANSI code page) by default rather than UTF-8, unless explicitly told otherwise |
Compatibility & gotchas
- "ANSI" in Windows dialogs usually means Windows-1252 (on Western-locale systems) — when older Windows software or "Save As" dialogs say "ANSI" rather than a specific charset name, that's almost always Windows-1252 under the hood, not any actual ANSI standard.
- Word/Outlook auto-convert straight quotes to curly quotes by default ("smart quotes" / "AutoCorrect"), silently introducing Windows-1252-family characters into what might otherwise look like plain ASCII text — a frequent source of mysterious garbled punctuation after copy-pasting from Office apps.
- Excel's default CSV export charset varies by version and OS locale — recent versions offer a "CSV UTF-8" export option specifically because the plain "CSV" export historically uses the system's ANSI code page (Windows-1252 on Western-locale machines), which corrupts non-ASCII characters for anyone opening the file expecting UTF-8.
- Mislabeling Windows-1252 as ISO-8859-1 is extremely common in HTTP headers and HTML meta tags — many web servers and CMSs historically declared
charset=ISO-8859-1while actually serving Windows-1252-encoded content, since the two are identical outside the narrow 0x80–0x9F range and the mismatch went unnoticed for years. - The WHATWG/HTML5 spec actually mandates this behavior — per the HTML Standard, when a page declares
charset=ISO-8859-1(or several related legacy labels), browsers are required to treat it as Windows-1252 anyway, codifying the mislabeling as a permanent compatibility rule rather than trying to fix it retroactively.
Fixing it
- Command-line conversion:
iconv -f WINDOWS-1252 -t UTF-8 input.csv -o output.csv— the standard fix for files exported from Excel/Windows tools that need to become proper UTF-8. - Excel exports: use "CSV UTF-8 (Comma delimited)" as the save format explicitly if your Excel version offers it, rather than the plain "CSV" option, to avoid the Windows-1252 default entirely.
- Word/Outlook paste issues: disabling "smart quotes" autocorrect prevents the curly-quote substitution at the source, or alternatively, always convert final text through a proper UTF-8 pipeline before it reaches downstream systems rather than relying on plain-text copy-paste.
- Detecting the mismatch: if you see
“,â€,â€", or’specifically, that's almost always Windows-1252 smart-quote/dash characters double-decoded through UTF-8 — a very recognizable signature worth pattern-matching for during debugging.
Comparison
| Encoding | Key difference from Windows-1252 |
|---|---|
| ISO-8859-1 (Latin-1) | Identical outside the 0x80–0x9F range, which Latin-1 leaves as unused control codes instead of printable characters |
| ISO-8859-15 | A different fix for the "Latin-1 has no €" problem — swaps a few rarely-used Latin-1 symbols for € rather than using the unused control-code range |
| UTF-8 | Variable-width and covers all of Unicode; the specific "smart quote" mojibake signature (“ etc.) is the telltale sign of a UTF-8/Windows-1252 mismatch |
FAQ
Is Windows-1252 the same as ISO-8859-1?
Not quite, though they're identical for the vast majority of characters. The difference is entirely in the 0x80–0x9F byte range: Windows-1252 defines printable characters there (curly quotes, dashes, €), while ISO-8859-1 leaves that range as unused control codes. Text using only characters outside that range is genuinely identical in both encodings.
Why do smart quotes from Word turn into weird symbols online?
Word's AutoCorrect converts straight quotes to Windows-1252-style curly quotes by default. If that text later gets processed as UTF-8 without properly converting the encoding first (or the reverse — UTF-8 text gets misread as Windows-1252), those specific curly-quote and dash characters corrupt into the recognizable “/â€/â€" mojibake pattern.
Why does my CSV from Excel show garbled accented names when I open it?
Excel's default "CSV" export often uses your system's ANSI code page (Windows-1252 on Western-locale Windows) rather than UTF-8. If the tool reading the CSV expects UTF-8, any accented characters (names, addresses) will show as mojibake. Look for a "CSV UTF-8" export option in Excel, or convert the file with iconv afterward.
Why does a page declaring "ISO-8859-1" sometimes render Windows-1252 characters correctly?
Per the HTML5/WHATWG spec, browsers are required to treat pages labeled ISO-8859-1 as Windows-1252 instead — a deliberate compatibility rule, since so much real-world content mislabeled Windows-1252 content as ISO-8859-1 for years and browsers standardized on "just treat it as 1252" rather than breaking that content.
Fun fact
The HTML Living Standard doesn't just tolerate the ISO-8859-1/Windows-1252 mislabeling — it formally mandates it. The spec's encoding-sniffing algorithm explicitly maps the label "iso-8859-1" (and several aliases) to the Windows-1252 decoder, meaning "correctly" following the modern HTML spec requires implementing what was originally a widespread bug.