JSON Tooling in 2026: Repair Grew 9x and Everything Else Grew 2x

Most writing about developer-tool adoption is built on surveys, and surveys ask people what they use. This page uses a different instrument: the npm downloads API, which records what build machines installed.

Read correctly it is useful; read naively it is a lie. Two things it is not:

• Not a count of people. One developer with a warm cache and a CI runner per pull request can produce thousands of "downloads." Everything below is installs, not users.
• Not a count of choices. A package pulled transitively is credited exactly as loudly as one someone chose on purpose.

The window is 2024-10-01 through 2026-10-10, pulled on 2026-10-11. "First" is its first 30 days, "last" its final 30. Swap the package name at the end of the URL above to reproduce any figure.

The five numbers

Nothing else is in this table, and the first two rows start hundreds of times smaller than the last three. Hold that on every percentage below.

2x is the waterline, not a finding

Prettier, js-yaml, and json5 do three unrelated jobs — a formatter, a YAML parser, a JSON superset — and they grew +202%, +198%, +196%. Three tools, three audiences, growth rates within a few points of each other.

That coincidence is the useful part. It is a baseline: what happens to a mature package when the ecosystem around it merely gets bigger — more CI runners, more containers rebuilt from scratch, more lockfiles resolved. A tool that doubles alongside the whole npm economy did not do anything. It aged.

So the question is only about the rows that broke the waterline: jsonrepair at +928%, and lossless-json at +265%, marginally above it.

Repair is a category. Permissive dialects are not growing.

json5 is what you install when someone hands you JSON with comments, trailing commas, or unquoted keys. It is mature, cheap, and a drop-in. If the JSON circulating in 2026 were messier in the human sense — people writing config the way they write JavaScript objects — that growth belongs to json5. It should be in the 9x row.

It is in the 2x row: +196% against +928%, a growth rate more than four times slower. That gap is why I don't think the change is "people write sloppy JSON." I think the input is damaged rather than non-standard, and those are different failures needing different tooling:

• A superset parser handles deliberate deviation — a dialect with a grammar, chosen on purpose.
• A repair library handles accidental deviation — bytes lost, added, or cut off mid-stream.

json5 cannot help with a response that stops mid-object because a proxy timed out, or with a model that emitted Here is the JSON: above a fenced block and never reached the closing brace. Damage is not a dialect.

My reading of the +928%: the average JSON arriving at a parser is now generated and truncated more often than it is hand-written and commented. LLM output, streaming responses cut at a token limit, tool-call payloads assembled from partial chunks, config hand-edited at 11pm and committed with the comma still wrong. "Almost JSON" got big enough to need its own dependency.

lossless-json is the corroborating weak signal. If the dominant new pain in generated JSON were numeric precision — big IDs, exact decimal amounts — a precision-safe parser should move with the repair library. It moved +265%, barely off the waterline. The damage is structural (brackets, commas, quotes, truncation) far more often than it is numeric — a prediction from the repair-side story that survives this data, which is at least weak evidence the story has the right shape.

Where I could be wrong

• One dependency, not one category. A popular editor extension or agent framework adding jsonrepair to its manifest produces a 9x curve that belongs to that product's rollout, not to a shift in what people parse. I did not inspect the dependent graph and this API does not break it out.
• Small base, loud percentage. 17.4M in the recent window is still smaller than json5's 365M in the older window. In absolute installs added, js-yaml — starting hundreds of times higher — dwarfs jsonrepair. These percentages describe direction of travel, never audience size.
• Infrastructure noise. A mirror changing cache policy, a package manager changing resolution, a CI provider switching images: all inflate every row at once. Which is why the 2x cluster matters — it is the control group, and it is what lets me treat 9x as signal at all.

One thing none of the five does

All five parse or print; none is a canonicaliser. If you are hashing a payload, signing a request, or diffing documents for an audit, key order, number formatting, and whitespace must be pinned first — and that is a specified problem: RFC 8785, JSON Canonicalization Scheme. Do not assume a formatter gives you determinism.

What to actually do with this

• Validate strictly at the boundary; repair only where a human is looking. A repair step inside an automated pipeline turns a loud crash into silently wrong data — the one failure mode you cannot detect later. Repair belongs in the last mile: an editor, a paste box, a config loader that prints what it changed. The Auto-Repair on this site is three regex substitutions and nothing more — the cheatsheet is blunt that it is a diagnostic, not a preprocessor.
• If a model generates your JSON, fix the generator before the parser. Structured output, smaller expected payloads, a schema the decoder enforces. Then count how often you need to repair at all and treat that ratio as a bug with a number attached. I am not giving you a threshold, because I have not measured anyone's pipeline — the point is to have the number at all.
• Truncation is not repairable. No library invents bytes that were never sent. If a real share of your repair events are "unterminated string" or "unexpected end of input," the fix is upstream — the timeout, the token limit, the write buffer — and the format that tells you which record got cut is line-delimited: NDJSON and JSONL guide.
• Put IDs on the wire as strings. Cheaper than adopting a precision-preserving parser to rescue numbers you should never have sent. Mechanics in JSON in JavaScript, 2024–2026.
• Pick a dialect on purpose, or don't have one. If humans edit your config, adopt JSON5 or JSONC and parse with a real parser that documents its rules. The worst position is a de-facto dialect cleaned up by regex.
• Normalise before you diff or hash. The diff tools page covers what each option actually guarantees. The JSON diff tool on this site is array-order-sensitive and stops recursing at 64 levels deep, which is a simplification worth knowing before you rely on it.

The optimistic reading of a 9x repair market is that tooling is getting better at surviving bad input. The pessimistic one is that we shipped a decade of JSON producers and are now paying for parsers that pretend not to notice. The second is cheaper to act on: decide which inputs you will refuse, and make that refusal loud.

Numbers pulled from the npm downloads API on 2026-10-11, 30-day windows. Installs, not people. If you build something that depends on this reading, check the endpoint yourself — it takes about a minute, and I would rather be checked than trusted.