demo · v139

Encoding Detection

Drive Chrome's byte-stream decoder with a real blob-backed HTML document. Compare explicit charset declarations, the Chrome 139+ no-sniff branch, and the pre-v139 ISO-2022-JP auto-detection branch that motivated the removal.

byte-stream workbench

Select sample bytes or paste your own hex. The probe builds an HTML byte stream, loads it into a sandboxed same-origin iframe, then reads document.characterSet, document.inputEncoding, and rendered text from the iframe.

current Chrome parser Not run

Run the probe to read the iframe document's resolved encoding.

explicit TextDecoder Not run

Uses TextDecoder("iso-2022-jp") on the same bytes.

utf-8 fallback Not run

Uses the default TextDecoder() fallback.

security branch Not run

Shows why implicit ISO-2022-JP sniffing was removed.

engine branch resolved encoding rendered text decision reason
Chrome 139+ — — —
pre-v139 heuristic — — —

probe document preview

byte and decoder analysis

Run the probe to inspect byte signatures, explicit decoder output, and the generated Content-Type.

the fix

If the response is HTML, choose one encoding and declare it before the browser starts parsing. The removal targets only automatic ISO-2022-JP detection; explicit ISO-2022-JP remains decodable when the server names it.

<!-- Prefer UTF-8 for new pages. -->
Content-Type: text/html; charset=utf-8
<meta charset="utf-8">

<!-- Existing ISO-2022-JP pages must be explicit. -->
Content-Type: text/html; charset=iso-2022-jp
<meta charset="iso-2022-jp">

why this changed

The ChromeStatus entry calls out known charset auto-detection security issues and an extremely low use counter for ISO-2022-JP auto-detection. The risky branch in this demo is exactly that combination: HTML bytes contain an ISO-2022-JP escape signature, but neither the HTTP header nor the markup declares the charset.

see also