Should you use json_repair?
Choose it when rejecting malformed JSON would discard useful input and your application can check the recovered values. json_repair repairs malformed JSON in Python. The documented repairs include missing quotes, commas and brackets, plus truncated values. Those repairs can make input parseable without proving that its values are correct.
Our run on September 27, 2026, at commit 8d124ec installed and built successfully, but the test command failed. The practical next step is to test your own malformed samples, including examples that should be rejected, before adding repair to an ingestion path.
What our sandbox established
The recorded environment used the Python 3.12 Bookworm image with 3 CPUs and 8 GB RAM. Installation took 29 seconds and the build took 5 seconds, both returning exit 0. The test command returned exit 1 after 10 seconds.
The harness stores each command's outcome, exit code, elapsed time and timeout flag alongside parsed test summaries and log tails. The attached stored parser summaries report 238 passed, 6 failed and 92 skipped, with 244 as the passed-plus-failed total. These are parser summaries, not verified exhaustive counts of unique tests. Skipped tests are not failures.
The raw pytest footer separately says "6 failed, 238 passed, 92 skipped in 2.78s". The 2.78 seconds belongs to that footer; the harness records 10 seconds for the command. Repeated failure lines in the supplied tail are not additional failures.
The six named failures cover schema-guided parsing, array and object schema paths, and missing-value or union repair. Every listed failure ends with the message "jsonschema is required when using schema-aware repair." The record establishes that these cases failed in our environment. It does not establish a successful schema-extra installation or what a rerun would produce.
The audit recorded 0 advisories. Scan coverage is unknown because the record does not supply scannedPackages; the dependency count cannot fill that gap. This result does not establish security. Nor do successful installation and build commands establish CLI behavior, application deployment, repair accuracy on production traffic or runtime throughput. We performed no new execution for this correction.
The MrKeyoor testing methodology explains how command outcomes and parsed summaries reach our reviews. That page describes the publisher's methodology; it does not establish that this September run used its later October revision.
Keep valid input on the default path
The README at the tested commit says the default path tries the standard-library JSON loader and invokes the repair parser only when strict JSON parsing fails. Keep that path for traffic containing both valid and malformed JSON.
The documented skip_json_loads option bypasses that check. The README warns that sending valid JSON directly through the repair parser can change structure or values. Use it only when input is already known to be invalid, rather than treating it as an equivalent performance switch.
Repair also needs an acceptance policy. Check required fields, allowed values and business rules after recovery. For a payment amount or permission change, a parseable result alone is insufficient grounds to act.
Treat schema repair as a separate adoption decision
The tested README labels schema-guided repair beta and says bugs are expected. It documents an optional schema extra and guidance from JSON Schema or a Pydantic v2 model. Schema guidance can fill missing values, coerce scalars and drop properties or items that the schema disallows. Those operations can change the data you retain.
Strict mode instead raises errors for structural problems such as duplicate keys and missing separators. Schema guidance and strict mode are mutually exclusive. Decide whether a particular input path permits recovery or requires rejection, then test that policy explicitly. Our failed schema cases leave that feature unverified in the recorded environment.
Which alternatives fit different inputs?
jsonrepair provides a streaming API for Node.js. Consider it as a replacement for the repair layer when your application needs Node.js stream integration. Its README also documents a buffer constraint: the buffer must accommodate the largest string and whitespace in the input. Streaming support alone does not remove that operational limit.
JSON5 is intended for handwritten configuration rather than machine-to-machine communication. Choose its parser when the producer deliberately writes JSON5 syntax, including comments or trailing commas. It defines an accepted input format; it does not serve the same purpose as recovering arbitrary damaged model output.
Validation remains a complementary step whichever repair implementation you choose. A parser's successful output does not establish your application's acceptance rules.
How to read the scores
These editorial scores use a five-point rubric: 1 means substantial obstacles, 2 means material limitations, 3 means usable with a demonstrated caveat, 4 means strong evidence within a limited scope, and 5 means thorough coverage of the assessed area. They are judgments, not benchmarks or adoption measurements.
Setup ease is 3 because installation and build succeeded while schema-focused tests failed. Documentation is 5 for its explicit defaults, warnings, mode restrictions and CLI descriptions, not for independently verified behavior of every example. Community is 4 narrowly for visible maintenance evidence: the supplied 0.63.5 release lists fixes for positive exponents and numeric-prefix identifiers, and issue 230 records completion. It does not measure contributor breadth or support availability. Maturity is 4 for the documented core parser and targeted fixes, qualified by beta schema repair and our failed test command.