is-my-json-valid

A code-generating JSON Schema validator built for raw speed in Node.js applications.

Library
npm
v2.20.6
963stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
53/100Fair
Development Activity48
Maintenance4
Community72
Maturity60
Momentum28

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
67/100Good
Architecture78
Code Quality65
Innovation78
Learning Curve45

is-my-json-valid compiles JSON Schema (draft-4) definitions into standalone JavaScript validation functions instead of walking the schema tree at runtime, which is why it benchmarks as one of the fastest validators available for Node.js. It passes the full JSON Schema draft-4 test suite except for remoteRefs and certain unicode-surrogate edge cases in minLength/maxLength.

Beyond a simple pass/fail result, it supports verbose error reporting with field paths and schemaPath breadcrumbs, a greedy mode that collects every failing rule instead of bailing on the first, a filter() helper that strips properties not declared in the schema, and pluggable custom formats plus external $ref schemas. Shipped TypeScript typings let consumers infer the shape of validated data directly from the schema object.

What You Get

  • Code-generated validate() functions compiled per-schema for near-native execution speed
  • Verbose error mode reporting field, message, value, type, and schemaPath for each failure
  • A filter() helper that deletes properties not declared in the schema
  • Support for custom formats, external $ref schemas, and a require() loader for schema files on disk

Common Use Cases

  • Validating incoming HTTP request bodies before they reach business logic
  • Enforcing configuration file shape at application startup
  • Stripping unexpected fields from user-submitted documents via schema-based filtering
  • Deriving TypeScript types for JSON payloads from a shared schema definition

Under The Hood

Architecture The library is built around a single recursive compiler: visit() in index.js walks the JSON Schema tree and emits JavaScript source lines through generate-function’s builder, accumulating a scope object of closures (compiled regex patterns, format validators, $ref proxies) that the generated code closes over before .toFunction(scope) evaluates it into a real function. Circular and forward $refs are handled with a lazy-proxy pattern — a placeholder function is registered in a cache before the referenced sub-schema is itself compiled — and require.js layers file-system schema loading (with .schema/.json extension fallback) on top of the same compile() core used by the main export and its filter() variant.

Tech Stack Plain CommonJS JavaScript with no build step for the runtime code itself; a small, focused dependency set (generate-function, generate-object-property, is-my-ip-valid, jsonpointer, xtend) does the code-emission and IP-format validation work. TypeScript typings are shipped separately in index.d.ts and checked via tsc as part of the test script, with Travis CI running the suite on each push.

Code Quality Tests run under tape and include the official JSON Schema draft-4 conformance suite alongside hand-written cases for edge behaviors (safe-regex handling, schema-path reporting, required/unique conflicts) plus a typings.ts file that exercises the TypeScript definitions. There’s no dedicated linter or formatter configuration in the repo, and inline comments are sparse relative to the file’s density, but the conformance-suite coverage and typing tests give real confidence beyond what comment density alone would suggest.

API Design The public surface is minimal: a single validator(schema, opts) call returns a validate(data) function with a boolean return value and .errors/.error getters attached, mirroring conventions later popularized by validators like ajv. The filter() submodule and require() file-loader reuse the same core with one extra flag or a path argument, so there’s very little boilerplate to get from an installed package to a working validator, and every option (custom formats, external schemas, verbose, greedy) is demonstrated with a runnable code sample in the README.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search