JSON response bytes: UTF-8, BOMs and unexpected HTML

Confirm that the body is JSON

An authentication redirect or gateway error can return HTML where the application expects JSON. HTTP 200 alone does not identify the body.

Inspect status, final URL and Content-Type before copying the response into JSON Validator; an HTML document needs a transport or authentication fix.

Expected: application/json
Unexpected first bytes: 3c 21 44 4f 43 54 59 50 45
ASCII: <!DOCTYPE

Locate a byte order mark

RFC 8259 requires UTF-8 for JSON exchanged outside a closed ecosystem. Producers must not add a BOM, though parsers may ignore one.

Inspect the downloaded body with Hex Dump. A browser decoding layer may already have removed a UTF-8 BOM, so pasted text is incomplete byte evidence.

UTF-8 BOM: ef bb bf
{"ok":true}: 7b 22 6f 6b 22 3a 74 72 75 65 7d

Separate compression and characters

Content-Encoding describes transport compression; UTF-8 describes text bytes after decompression. Compressed bytes cannot be parsed directly as JSON.

If the browser has already decompressed the response, do not decompress it again. Check the client library contract rather than guessing from a filename.

Fix the producer and preserve evidence

Test a tiny UTF-8 response without a BOM and confirm it parses in the receiving runtime. Then compare the failing body's leading bytes.

Removing a confirmed BOM can be a documented compatibility step. Replacing arbitrary leading text or applying JSON repair would hide the actual failure.