Malformed Payload Tester

cat ./tldr.txt

A malformed JSON tester serves deliberately broken payloads — a body truncated mid-array, single quotes and trailing commas, or an HTML gateway error page sent with a JSON content type — so response parsing, catch blocks, and fallback UI can be hardened before production does it for you.

./when-to-use-this

• → Your code calls response.json() with no catch and you want to see exactly how it fails.
• → A load balancer occasionally returns an HTML 502 page under a JSON content type and your client reports a confusing error.
• → You are writing a resilient API client and need reproducible bad input for its test suite.

./frequently-asked

Why does the editor mark these payloads as invalid?

Because they are, deliberately. On this tool the validator shows an amber "intentionally malformed" state rather than a red error, and the broken bytes are preserved exactly through the URL rather than being normalised. That fidelity is the whole point — a re-serialised payload would no longer reproduce the parser failure.

What actually happens when response.json() fails?

It returns a rejected promise with a SyntaxError, not a thrown value you can catch synchronously. Code using await needs try/catch and code using .then() needs a .catch(), and neither should assume a failed parse means the request failed — the HTTP status may well have been 200.

Which malformation should I test first?

The HTML-disguised-as-JSON case. Truncated bodies and bad syntax are rare in practice, but a proxy or gateway returning an HTML error page with a JSON content type is common in production and produces the notoriously unhelpful "Unexpected token < in JSON at position 0" error.