When converting legacy encodings to Unicode, multiple organizations created their own mapping tables independently. The official Unicode.org tables followed national standards strictly, while Microsoft and later WHATWG followed what browsers actually implemented.

WHATWG’s fundamental principle: “Don’t break existing web content.” This means ratifying browser behavior even when it contradicts official standards.

The most well-known mapping conflict. The same JIS byte position maps to different Unicode code points:

This tool lets you toggle between both mappings in Settings to see the difference.

Big5 (Traditional Chinese): WHATWG merges CP950 and HKSCS into a hybrid table. 6 characters have duplicate byte positions where the encoding order differs between WHATWG and other implementations.

GB18030 (Simplified Chinese): Byte 0xA3 0xA0 maps to U+3000 (ideographic space) in WHATWG, but the official GB18030 standard maps it to U+E5E5 (a PUA character). This was a deliberate web-compatibility fix from 2002.

WHATWG’s “EUC-KR” is actually Windows CP949/UHC, covering all 11,172 Hangul syllables — far more than the original KS X 1001 standard’s ~2,350.

Notably, the Unicode.org KSX1001.TXT was created from Microsoft’s UHC mapping (stated in the file header), so there is no WHATWG vs Unicode.org discrepancy for Korean — unlike JIS.

WHATWG’s most sweeping decision: all labels including iso-8859-1, latin1, and ascii resolve to Windows-1252. This means 27 bytes in the 0x80-0x9F range decode as typographic characters instead of C1 controls.

Across all encodings, the pattern is the same:

WHATWG standardized what browsers had been doing for decades. The result is pragmatic but means “the standard” and “browser behavior” now agree — at the cost of diverging from the original national standards.