DEV Community: sharpenlee

Why LLMs return invalid JSON — a language model has no parser

sharpenlee — Sun, 11 Oct 2026 06:38:56 +0000

Ask a model for JSON and you often get something that is almost JSON: a value wrapped in a markdown fence, a trailing comma, a Python None where null belongs. The reflex is to blame the prompt, or to switch on "JSON mode". Both miss the mechanism. A language model predicts the next token; it never builds a document, and it cannot tell you that a document is broken, because nothing in it represents a document. The useful question is therefore not "how do I make it stop" but "where does the parser go, given there is not one upstream".

What comes back

The twelve source strings below are the shapes that actually break things — eight of them are repairs that the jsonrepair library documents by name. I ran all twelve through four parsers and recorded accept-or-reject. They were typed as literals rather than captured from a live call: there is no API key on the machine this was written on, so the shapes are the documented ones and what is measured here is how the parsers respond to them.

Source	Node	Python	Ruby	PHP
markdown fence	ERR	ERR	ERR	ERR
trailing comma `{"a":1,}`	ERR	ERR	ERR	ERR
single quotes `{'a':1}`	ERR	ERR	ERR	ERR
Python literals `None / True`	ERR	ERR	ERR	ERR
block comment `/* … */`	ERR	ERR	OK	ERR
raw newline inside a string	ERR	ERR	ERR	ERR
truncated `{"a":1,"b":[1,2`	ERR	ERR	ERR	ERR
`NaN`	ERR	OK	ERR	ERR
`Infinity`	ERR	OK	ERR	ERR
unquoted key `{a:1}`	ERR	ERR	ERR	ERR
trailing prose after the value	ERR	ERR	ERR	ERR
UTF-8 BOM before the object	ERR	ERR	ERR	ERR

Four parsers, twelve documents, and they agree on almost all of it. Nine of the twelve are rejected by every parser in the table, which is the reassuring part: for a fence, a trailing comma, a stray quote or a truncation, none of the mainstream parsers you are likely to be running will accept the text as JSON. Three rows break the unanimity, in two ways that matter more than they look.

Ruby accepts block comments

Ruby 2.6.10 — the build measured here, with its bundled json 2.1.0 — parses {"a":1 /* note */} and hands back {"a"=>1}. Every other parser in the table refuses it. So the exact bytes that are a hard 400 from a Node or PHP service are a clean 200 from a Ruby one. This is obscure, and that is the point: a strict parse is not a shared contract between two services in the same pipeline unless they happen to run the same parser.

Python accepts NaN and Infinity

JSON's number grammar has no NaN and no Infinity — RFC 8259 builds every number from an optional minus, digits, an optional fraction and an optional exponent, and those tokens are not in it. Node, Ruby and PHP reject {"x": NaN}. Python's json.loads returns {'x': nan}. Hand that value straight back to json.dumps and, with the default settings, you get {"x": NaN} — a document that is not valid JSON and that the other three parsers reject on sight; only allow_nan=False turns the silent round trip into an exception. This is the same divergence the companion article on number precision found from the write side; here it arrives from the read side, in data a model just produced.

There is no guarantee upstream, by construction

The reason models get this wrong is not that they are bad at JSON. It is that the mechanism cannot make the promise. Sampling emits one token at a time from a probability distribution; nothing in the loop represents "the text so far is a complete, well-formed document", so nothing in the loop can refuse to finish it. A constrained decoder does better — it can track whether the text so far is a valid prefix — but a valid prefix is not a valid document, and that gap is the whole story.

"JSON mode" is the vendor term for pushing that guarantee as far upstream as it will go, and the documentation is unusually direct about what it actually buys you. Microsoft's Azure OpenAI page states that JSON mode "guarantees valid JSON output, but it doesn't guarantee the output matches a specific schema". The braces will close; the fields inside them can still be wrong. The same page shows how thin even that guarantee is at the edges — it also requires the word "JSON" to appear somewhere in the messages, and when it does not, the API rejects the request outright:

Error code: 400 - {'error': {'message': "'messages' must contain the word
'json' in some form, to use 'response_format' of type 'json_object'."}}

That error is the honest shape of the whole feature. When the instruction is missing, the documentation warns (quoting OpenAI) that the model can "generate an unending stream of whitespace and the request could run continually until it reaches the token limit" — a failure that looks, from your side, exactly like a hang.

The hole the guarantee does not cover

Validity per token is not validity per document, and the place they diverge is truncation. If the reply is longer than max_tokens, the stream simply stops mid-structure and finish_reason comes back as length. Azure's guidance is explicit on both counts: "You should check finish_reason for the value length before parsing the response. The model might generate partial JSON", and, in troubleshooting, "Don't parse partial JSON."

This is the case the guarantee cannot reach, and the case a repair layer is most likely to paper over. Take the truncated object from the table and let a repair pass close its brackets:

model (finish_reason: "length")
    {"a":1,"b":[1,2

after the repair pass closes the brackets
    {"a":1,"b":[1,2]}

The result parses cleanly, and it is a lie. Nothing in the text says whether the list was going to end at two items or fifty; the repair chose two. Repair restores syntax, never data.

The repair layer, measured

Since the parser upstream does not exist, one has to exist downstream, and in practice it is a repair pass that runs before JSON.parse. I wrote the smallest honest version of that pass and ran it over the same twelve documents. A first stage of plain regex substitutions — strip the fence and the byte-order mark, drop comments and trailing commas, swap the single quotes, map the Python and JavaScript non-values, close unbalanced brackets — recovered nine of the twelve. The three it missed were simply rules that first pass did not contain, and two of them are cases a regex cannot handle safely on its own: a newline must be escaped only when it is inside a string, and trailing prose must be cut only once the value has ended. Adding a boundary-tracking pass, and the key-quoting rule, took it to twelve out of twelve:

Source pattern	After repair	What the repair did
markdown fence	parses	stripped the fence
trailing comma	parses	removed it
single quotes	parses	rewrote as double quotes
`None` / `True`	parses	mapped to `null` / `true`
block comment	parses	removed the comment
raw newline in a string	parses	escaped the control character
unquoted key	parses	added the quotes
trailing prose	parses	discarded everything after the value
UTF-8 BOM	parses	stripped the mark
`NaN` / `Infinity`	parses	substituted `null` — a value the model never wrote
truncated	parses	closed the brackets — and invented the data above

All twelve parse afterwards. The truncated one parses by being falsified. And some of those rows are decisions rather than restorations: the comment row silently dropped content the model took the trouble to write, and the NaN row is worse — the substituted null is indistinguishable from a real one, so a repair pass can convert "the model produced an undefined number" into "the model said there is nothing here" without leaving a trace.

None of this is improvisation on my part. The jsonrepair library publishes a list of what it fixes, and eight of the twelve shapes above are on it by name: add missing quotes around keys, add missing escape characters, repair truncated JSON, replace single quotes with double quotes, replace Python constants, strip trailing commas, strip comments and strip fenced code blocks. Three of the shapes it does not cover are the ones that matter most — NaN, Infinity and prose trailing after the value. Those are exactly the cases that survive a repair pass silently: NaN parses in Python and nowhere else, so a pipeline can carry it through the repair stage and lose it at whichever service happens to disagree. That a dedicated repair library and a model's failure modes overlap this heavily is the clearest evidence that the problem is structural rather than incidental.

What to do instead

Move the guarantee upstream when you can. Prefer a schema-constrained mode over asking politely in the prompt: the documented difference is that JSON mode promises syntax while structured outputs constrain the model to a schema. Neither was exercised here (no API key), so treat the exact semantics as documented rather than measured.
Treat the reply as untrusted text. The pipeline is repair → parse → validate against a schema, in that order, and the last step is not optional, because a syntactically perfect document with the wrong fields passes the first two.
Check finish_reason before you parse, and never repair a truncated reply into acceptance. Raise and retry with a larger budget instead. Repair makes a cut-off document look finished; only you can decide that it is not finished.
Do not assume "valid JSON" is a shared contract. Two services in one pipeline can disagree about the same bytes — Ruby takes the block comment, Python takes the NaN, and the third service rejects both. Validate at the boundary rather than trusting that the upstream parser agreed with yours.
Look at the output before it reaches code. A repair layer hides exactly the cases you most need to see.

Check your own payload

Paste a model reply into the validator to get the line and column of the first real error rather than a repair that is invisibly wrong, and into the formatter to see the structure once it parses. For output that is valid JSON but the wrong shape, the JSON Schema validator is the missing test: "parses" and "correct" are different questions, and JSON mode only answers the first. The syntax cheat sheet covers what the grammar actually allows, including why NaN and Infinity are not in it.

Provenance

The parser table and the repair table were produced by running the documents shown through Node 24.18.0 on V8 15.0.245.15, CPython 3.10.11, Ruby 2.6.10 (bundled json 2.1.0) and PHP 8.3.35 on a 64-bit build. The Node runtime here is the one embedded in an Electron host rather than a stock Node distribution — its V8 build string carries an -electron suffix — and the parser exercised in either case is V8's own JSON.parse. The repair pass was written and executed for this article rather than taken from a library, and the Python NaN round trip was measured with the default json.dumps and again with allow_nan=False. The twelve source strings are the documented failure shapes rather than captures from a live call: there is no API key on the machine this was written on, so nothing here was produced by a model. The claims about JSON mode, structured outputs and finish_reason are quoted from Microsoft's Azure OpenAI documentation, which mirrors OpenAI's, and are labelled documented rather than measured for exactly that reason; the jsonrepair list is quoted from that library's repository README, which enumerates its repairs without naming models as their source.

JSON number precision — why 19-digit IDs come back wrong — the same "the parsers disagree" problem, measured from the write side.
JSON Schema validator — the check that catches a reply which parses but has the wrong shape.
JSON guides — everything published so far.

JSON Number Precision — Why 19-Digit IDs Come Back Wrong

sharpenlee — Fri, 02 Oct 2026 14:09:44 +0000

Here is one line of JSON, parsed and re-serialised, changing a digit on the way through. No error, no warning, nothing to catch:

in:  {"id": 9007199254740993}
out: {"id": 9007199254740992}

It is tempting to conclude that JSON is lossy. It is not. Run the same document through Python or Ruby and the ID survives intact — which means the damage was done by a choice the JavaScript engine made, and that the standard explicitly permitted.

One document, three answers

Every result below was produced by running the code, not by reading documentation. Three commands, one payload:

node    -p 'JSON.parse("{\"id\":9007199254740993}").id'
python3 -c 'import json;print(json.loads("{\"id\":9007199254740993}")["id"])'
ruby    -rjson -e 'p JSON.parse("{\"id\":9007199254740993}")["id"]'

Runtime	What you get back	Type
Node v24.18.0 (V8 15.0)	`9007199254740992`	`number`
CPython 3.10.11	`9007199254740993`	`int`
Ruby 2.6.10	`9007199254740993`	`Integer`

Two of the three are exact. The odd one out is the language most JSON is written in, and it is the only one of the three whose integers are not arbitrary-precision: JavaScript has one numeric type, a 64-bit float, so anything above 2**53 - 1 is rounded on the way in. A 19-digit snowflake ID, a nanosecond timestamp, an Ethereum amount — all of them sit well past that line.

The damage can happen before JSON is involved

In JavaScript the rounding is not a property of the parser. It is a property of the number, and it applies to literals in your source too:

9007199254740993 === 9007199254740992   // true
1.0000000000000000001                   // 1

So by the time JSON.parse is called, a numeric ID may already have been corrupted by the code that built the value. This is why "just use a bigger type" does not work in JavaScript: the bigger type does not exist, and the literal syntax will not warn you.

What the standard actually promises

RFC 8259 does not require a lossy parser. It permits one. It allows implementations to set their own limits on range and precision, and the only numbers it promises will interoperate are those inside the window [-(2**53)+1, (2**53)-1]. It names the smell itself: "A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems".

That, in one sentence, is the whole problem. JSON defines a grammar for numbers, not a numeric type. The grammar says a number is an optional minus sign, digits, an optional fraction and an optional exponent. It says nothing about how many digits matter or what they mean once decoded. Every implementation then binds that grammar to whatever number type it already had, and the binding is where your ID dies.

It applies to keys as well

The same laissez-faire applies to object keys. RFC 8259 says "The names within an object SHOULD be unique", and then concedes what happens when they are not: "the behavior of software that receives such an object is unpredictable". All three runtimes I tested take the last value, but nothing in the standard requires that, which is why a duplicated key is a live security question rather than a style question — a proxy and the service behind it can disagree about which value the document means.

Reading is only half of it

The write side is worse, because it destroys information that was never in doubt. These are measured, not theoretical:

Value	JavaScript	Python	Ruby
`1.0`	`1`	`1.0`	`1.0`
`1.10`	`1.1`	`1.1`	`1.1`
`NaN`	`null`	`NaN` — invalid JSON	raises `GeneratorError`
`Infinity`	`null`	`Infinity` — invalid JSON	raises `GeneratorError`
`-0.0`	`0`	`-0.0`	`-0.0`
`2**53 + 1`	`9007199254740992`	`9007199254740993`	`9007199254740993`

Three things are worth pulling out of that table.

JavaScript turns NaN and Infinity into null. Not an error, not a string — null, which is indistinguishable from a genuine absent value. Python takes the opposite risk and writes NaN into the output, producing a document that is not valid JSON and that a strict reader will reject. Ruby refuses to write it at all, which is the correct behaviour and the least popular one.

1.10 loses its trailing zero everywhere. Not because a parser is lazy, but because 1.10 and 1.1 are the same IEEE 754 double — the trailing zero was never a value, only spelling. Only a reader that declines to convert to a double keeps it. That is the real dividing line in this whole subject: did the parser commit to a floating-point type, or did it keep the text?

The round trip is not a function. If you cannot recover your input from parse(stringify(x)), then comparing serialised JSON as text for equality is a bug waiting to happen. 1.0 becomes 1, -0.0 becomes 0, and 2**53 + 1 becomes 2**53 — all before you look at it.

The sign of zero shows how per-language this gets. Given the source text -0, JavaScript keeps the negative zero when parsing and then writes it back as 0; Python reads the very same token as the integer 0, losing the sign on the way in rather than on the way out. Identical bytes, two languages, two different places to drop the same bit.

And it silently discards non-numbers too

While we are on the write side, JSON.stringify in JavaScript does the following without complaint:

Input	Output
`{ a: undefined, b: 1 }`	`{"b":1}` — the key disappears
`[undefined]`	`[null]` — in an array the slot survives as null
`new Map([[1, 2]])`	`{}` — every entry gone, no error
`new Set([1])`	`{}`
`1n` (BigInt)	throws `TypeError`
`new Date(0)`	`"1970-01-01T00:00:00.000Z"`, and parsing it back gives a string, not a Date

Note the inconsistency between the first two rows: the same undefined is dropped from an object and replaced with null in an array. Neither is wrong per the standard — an array cannot have a hole, so something has to go there — but a reader who assumes symmetry will be surprised.

The 1e21 cliff

One more JavaScript-only oddity, because it breaks text diffs rather than values:

JSON.stringify(1e20)   // "100000000000000000000"
JSON.stringify(1e21)   // "1e+21"

Below 1e21 a number prints in full; at and above it, exponential notation. The value is identical, the bytes are not. Any tool that compares two payloads by their text — a cache key, a deduplication hash, a diff — will declare these different while any parser will say they are the same.

The escape hatch almost nobody knows

There is now a way to make JSON.parse and JSON.stringify round-trip byte-for-byte in JavaScript, and it is barely two years old. It comes from the TC39 JSON.parse source text access proposal, which is at stage 4, and it does two things: it gives the reviver a third argument carrying the original source text of each value, and it adds JSON.rawJSON for writing that text back out untouched.

That is enough to preserve a number exactly:

const keep = (key, value, ctx) =>
    ctx && 'source' in ctx ? JSON.rawJSON(ctx.source) : value;

const src  = '{"id":9007199254740993,"amount":1.10,"tag":"x"}';
const back = JSON.stringify(JSON.parse(src, keep));

// back === src  ->  true

Without the reviver the same transform silently rewrites the document — a changed digit and a reformatted decimal:

plain:  {"id":9007199254740992,"amount":1.1,"tag":"x"}
kept:   {"id":9007199254740993,"amount":1.10,"tag":"x"}

It works inside arrays too, and JSON.isRawJSON tells you when you are holding one of these wrappers. Two things to know before reaching for it. It is not a number — you cannot do arithmetic on it, so it belongs in pass-through code (a proxy, a logger, a formatter) and not in business logic. And the argument must be valid JSON on its own: JSON.rawJSON('01') throws immediately rather than corrupting anything downstream, which is a good failure to have.

Availability is the real limit. It is present in the runtime I tested, Node v24.18.0 on V8 15.0, and absent from older ones — check with typeof JSON.rawJSON before relying on it. On an engine without it, no reviver will help you, because the digits were gone before your callback ran.

What to do instead

Send identifiers as strings. This is what every large API eventually does, and it is the only fix that holds across languages, proxies and databases simultaneously. "9007199254740993" is exact everywhere; 9007199254740993 is exact in two of the three runtimes above and wrong in the third. A string is also self-documenting: nobody will accidentally sum it.
If you must keep numbers, parse with a reader that does not commit to a double. Python's default already keeps integers exact, and parse_float=decimal.Decimal keeps decimals exact too. Go's json.Decoder.UseNumber() and Jackson's USE_BIG_DECIMAL_FOR_FLOATS are the equivalent switches elsewhere; neither was executed here, so treat their exact semantics as documented rather than measured. In JavaScript, the reviver above is the option that exists today.
Refuse to write NaN and Infinity. Python needs json.dumps(..., allow_nan=False) to stop producing invalid JSON; Ruby does it already. In JavaScript there is nothing to enable — they are silently null, so the check has to be yours.
Never compare serialised JSON as text. 1.0 versus 1 and 1e20 versus 100000000000000000000 are the same values in different spelling. Compare parsed structures, and if you need a stable hash, canonicalise first — which means deciding what "equal" means for numbers before you hash, not after.

Where this bites in practice

The failure is concentrated in identifiers, and identifiers are exactly the values people are most reluctant to make strings because of how much legacy code compares them. Snowflake IDs from Twitter, Discord and the like; nanosecond timestamps at 19 digits; Ethereum amounts in wei, up to 78 digits; 64-bit hashes used as keys. Every one of them is past 2**53, and every one of them fails quietly — you get a valid-looking number that is off by a little, and the error surfaces three services later as "record not found".

Check your own payload

Paste the document into the JSON formatter to see the structure, and be aware of what you are looking at: this tool parses with your browser's engine, which is a V8-family parser, so a 19-digit ID will already be rounded when it appears on screen. That is not a limitation to hide — it is the same thing JSON.parse will do to that data in your application, demonstrated before you ship it. If the number looks wrong in the formatter, it is wrong in your code.

For documents that will not parse at all, the validator reports the line and column, and the syntax cheat sheet covers what the grammar allows.

Provenance

Every result in this article was produced by executing the code shown, on Node v24.18.0 (V8 15.0.245.15), CPython 3.10.11 and Ruby 2.6.10. The quoted sentences are from RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, sections 4 and 6; the proposal status is from the TC39 JSON.parse source text access repository. Where a claim was not executed here — the Go and Jackson settings — it is labelled as documented behaviour rather than measured, because the difference between those two things is the entire subject of this article.

Why "Unexpected token <" means your API returned HTML

sharpenlee — Thu, 01 Oct 2026 14:15:17 +0000

You called an endpoint, expected data, and the parser stopped on the very first character. The message is not about your payload — it is about the shape of the response, and the response was a web page.

Uncaught SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

Older engines report the same failure with different wording, and a search for any of these strings means the same thing:

SyntaxError: Unexpected token < in JSON at position 0

What the parser is telling you

A JSON document may begin with {, [, ", a digit, a minus sign, or one of the literals true, false and null. Leading whitespace is allowed. Nothing else is. A < is not in that set, so a body that starts with <!DOCTYPE html> fails at offset zero.

Newer V8 builds — Chrome, Edge and Node 20 and later — make the message far more useful by quoting the beginning of what they actually received. Those five characters, "<!DOCTYPE ", are the whole diagnosis: something gave you a hypertext document where you expected a data envelope.

The five things that actually happened

The endpoint returned an error page. A 404, a 500, or a framework's HTML error renderer answered instead of the route you meant. A path segment is missing, the route only exists for a different HTTP method, or the resource genuinely is not there.
A single-page app fallback answered instead of the API. Dev servers and static hosts commonly serve index.html for any unmatched path, so a request to a typo such as /api/uers returns the application shell — status 200, content type text/html. This is the most frequent cause in local development, and it looks exactly like a successful request.
You were redirected to sign-in. An expired session or a missing token turns the API call into a redirect to a login page, and fetch follows redirects silently. The parser then receives the sign-in form.
Something in front of the API blocked the request. A WAF, a corporate proxy, a CDN security rule or a captive portal serves an HTML interstitial, frequently with a status that does not read like a failure.
The base URL points at the marketing site. A missing /api prefix, an environment variable still set to the root domain, or a trailing-slash difference lands the request on a page that is perfectly valid HTML — just not the one you wanted.

Confirm it in one request

Print the status, the content type and the first bytes before parsing. This is the step that turns the error from a puzzle into a fact:

const res = await fetch(url, {
    headers: { Accept: 'application/json' }
});

const body = await res.text();

console.log(res.status, res.headers.get('content-type'));
console.log(body.slice(0, 120));

if (!res.ok) {
    throw new Error(`HTTP ${res.status} from ${res.url}: ${body.slice(0, 200)}`);
}
if (!res.headers.get('content-type')?.includes('json')) {
    throw new Error(`Expected JSON, got ${res.headers.get('content-type')}`);
}

const data = JSON.parse(body);

Reading with text() and parsing it yourself is what makes this work. Calling res.json() directly throws the same unhelpful syntax error and discards the body, which is why the cause stays hidden.

From a shell, the headers and the first line are enough:

curl -sS -i -H 'Accept: application/json' https://api.example.com/v1/users | head -n 20

The first line gives the status and content-type gives the type. If the body begins with <!DOCTYPE, you have your answer. Run it again without -L: curl will then print the redirect and its location header instead of following it, which is how you catch the login bounce that fetch hid from you.

Why sending `Accept: application/json` does not prevent this

It is a request header, not a contract. Servers are free to ignore it, and error paths in particular tend to bypass content negotiation altogether. It is still worth sending — some gateways route on it — but the reliable check is the status and the content type above, not the header you hoped would be honoured.

It works in Postman but fails in the browser

Two explanations cover nearly every case. Either Postman sends an API key or bearer token while the browser sends session cookies, so only the browser gets redirected to sign-in; or the server chooses its response format based on X-Requested-With, which fetch does not set by default. Compare the raw response rather than the Pretty view — Postman renders HTML without complaint.

Do not fix this by stripping the HTML

It is tempting to add a repair step that slices everything before the first { and parses the remainder. That converts a loud failure into a quiet one. The request is still wrong, and once the error page changes shape you will be debugging a half-parsed object instead of a 404. Fix the path, the authentication or the routing, and keep the guard from the snippet above so the next occurrence fails where you can see it.

Wording across engines

The same defect is reported differently depending on what parsed it. If your message is not the one at the top of this post, it is probably in this table:

Engine	Message
Chrome, Edge, Node 20+	`Unexpected token '<', "<!DOCTYPE "... is not valid JSON`
Chrome, Node before v20	`Unexpected token < in JSON at position 0`
Firefox	`JSON.parse: unexpected character at line 1 column 1 of the JSON data`
Safari, JavaScriptCore	`JSON Parse error: Unexpected identifier "<!DOCTYPE"`
Python `json.loads`	`json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)`

Check whether a body is JSON at all

Once the endpoint returns data, paste it into the JSON formatter to read the structure. If you are not yet sure whether a body is JSON at all, paste it in as it arrived: a < reported at position 0 is a definitive answer that the content type was lying, and the validator gives you the line and column rather than a bare offset.

DEV Community: sharpenlee

Why LLMs return invalid JSON — a language model has no parser

What comes back

Ruby accepts block comments

Python accepts NaN and Infinity

There is no guarantee upstream, by construction

The hole the guarantee does not cover

The repair layer, measured

What to do instead

Check your own payload

Provenance

Related

JSON Number Precision — Why 19-Digit IDs Come Back Wrong

One document, three answers

The damage can happen before JSON is involved

What the standard actually promises

It applies to keys as well

Reading is only half of it

And it silently discards non-numbers too

The 1e21 cliff

The escape hatch almost nobody knows

What to do instead

Where this bites in practice

Check your own payload

Provenance

Related reading

Why "Unexpected token <" means your API returned HTML

What the parser is telling you

The five things that actually happened

Confirm it in one request

Why sending `Accept: application/json` does not prevent this

It works in Postman but fails in the browser

Do not fix this by stripping the HTML

Wording across engines

Check whether a body is JSON at all

Related reading

DEV Community: sharpenlee

Why LLMs return invalid JSON — a language model has no parser

What comes back

Ruby accepts block comments

Python accepts NaN and Infinity

There is no guarantee upstream, by construction

The hole the guarantee does not cover

The repair layer, measured

What to do instead

Check your own payload

Provenance

Related

JSON Number Precision — Why 19-Digit IDs Come Back Wrong

One document, three answers

The damage can happen before JSON is involved

What the standard actually promises

It applies to keys as well

Reading is only half of it

And it silently discards non-numbers too

The 1e21 cliff

The escape hatch almost nobody knows

What to do instead

Where this bites in practice

Check your own payload

Provenance

Related reading

Why "Unexpected token <" means your API returned HTML

What the parser is telling you

The five things that actually happened

Confirm it in one request

Why sending Accept: application/json does not prevent this

It works in Postman but fails in the browser

Do not fix this by stripping the HTML

Wording across engines

Check whether a body is JSON at all

Related reading

Why sending `Accept: application/json` does not prevent this