Windows-1252 Hex Dump

Windows-1252 is the encoding behind countless mojibake bugs. This tool dumps the exact CP1252 byte for every character so you can see precisely how text like smart quotes and the euro sign is stored — and why it breaks when misread.

How it works

Windows-1252 is a single-byte encoding. For most of its range it matches ISO-8859-1 exactly, so the mapping is trivial:

0x00–0x7F : same as ASCII
0xA0–0xFF : same as ISO-8859-1
0x80–0x9F : CP1252-specific printable characters

The crucial part is that 0x80–0x9F range. Where Latin-1 reserves those bytes for control codes, CP1252 reuses them for €, –, —, ”, ”, ™ and other common symbols. The tool maps each character through this table; characters with no CP1252 byte are shown with a dash.

The 0x80–0x9F range in full

This is the region that causes almost all CP1252 vs Latin-1 confusion. Here is the complete mapping for those 32 bytes:

Bytes 0x81, 0x8D, 0x8F, 0x90, and 0x9D are undefined in CP1252 (they produce a replacement character or error when decoded). In ISO-8859-1, all 32 bytes in this range are control codes with no printable glyph.

Common mojibake scenarios

Word processor to web: Microsoft Word and older Windows applications output CP1252 by default. When pasted into a system that expects UTF-8, the smart quotes and dashes in the 0x80–0x9F range produce garbled characters. For example, the curly opening double quote ” (0x93 in CP1252) becomes “ in UTF-8 if the bytes are misinterpreted.

Database migrations: Databases that were set up as Latin-1 or CP1252 frequently cause problems when migrated to UTF-8. If you see garbled accented characters or replaced symbols after migration, the source data was likely CP1252 and was decoded as ISO-8859-1 (which maps those bytes differently) or as raw UTF-8 (which cannot parse them at all).

CSV and text file imports: Spreadsheet exports from Windows frequently use CP1252. If you open a CP1252 CSV in a tool expecting UTF-8, names with accented characters, currency symbols, or typographic dashes will appear corrupted. The fix is to declare the encoding explicitly when reading the file.

ANSI in Windows APIs: Many Win32 APIs that accept “ANSI” strings use the active code page, which defaults to CP1252 on Western Windows. When this string is passed to a UTF-8 or Unicode-aware context without re-encoding, mojibake follows.

How to fix CP1252 mojibake

Once you have identified that data was incorrectly decoded, the fix is to re-encode: read the bytes as CP1252 and write them as UTF-8. In Python, for example: bytes_object.decode(‘windows-1252’).encode(‘utf-8’). The hex dump this tool produces lets you verify the original bytes so you can confirm the source encoding before applying a fix.

Tips and notes

• The euro sign € is byte 0x80 in CP1252 but does not exist in Latin-1 — a classic source of broken imports.
• Curly quotes (” “ ‘ ‘) and the em dash (—) live in the special range, so text from Microsoft Word often needs CP1252-aware handling.
• A dash in the dump tells you the character is outside CP1252 entirely and would need UTF-8 to represent.
• Use this tool to confirm the encoding of suspicious text before deciding on a fix — knowing the exact bytes is the first step in resolving any encoding bug.