JSON Tooling in 2026: Repair Grew 15×, Precision 8×, Everything Else 3×

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-12. "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.

3× 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 +249%, +240%, +226%. Three tools, three audiences, and still close enough to read as one baseline.

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. These three triple on their own, for three unrelated reasons, by near-identical amounts. A package that rides the general inflation of npm install did not do anything. It aged.

So the question is about two rows, and the second is not marginal: jsonrepair at +14.9×, and lossless-json at +743%, several times the waterline rather than near 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 15× row.

It is in the waterline row: +226%, a ratio of 3.3×, against jsonrepair's 14.9×. On the ratio scale the repair library grew roughly four and a half times as much. 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 +14.9×: 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 row that broke my story. If the dominant new pain in generated JSON were numeric precision — big IDs, exact decimal amounts, long integers flattened through a float — a precision-safe parser should move with the repair library, and my earlier draft of this page reported it at +265% and called that "barely off the waterline", which was corroboration. The corrected pull says +743%: the second-fastest row here, well clear of the cluster, which is evidence against what I claimed rather than for it. What survives is only the ordering: repair grew about twice as fast as precision-safety, so structural damage (brackets, commas, quotes, truncation) still looks like the larger of the two problems. The clean two-bucket story does not survive; the weaker ordering claim does. I do not have a mechanism for the precision number, and I would rather leave it unexplained than fold it into a story it does not fit.

Where I could be wrong

• One dependency, not one category. A popular editor extension or agent framework adding jsonrepair to its manifest produces a 15× 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.45M in the recent window is still smaller than json5's 331.9M 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 3× cluster matters — it is the control group, and it is what lets me treat 15× 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.