Ajv: A JSON Schema Validator for Node.js and the Browser

The Problem Ajv Solves at a Request Boundary

Any service that accepts JSON from outside its own process has the same problem: the payload is a JavaScript object by the time you see it, and nothing about that object is guaranteed. Fields are missing, numbers arrive as strings, arrays contain objects where you expected strings. Writing those checks by hand produces code that drifts from the documentation and fails differently in each handler.

Ajv takes a schema document and turns it into a validation function. The schema is the single description of what valid input looks like, and the function is what enforces it. That matters most where the input is untrusted or where two systems written by different teams have to agree on a shape: HTTP request bodies, message queue payloads, configuration files loaded at startup, and fixtures in a test suite.

The audience is JavaScript and TypeScript developers working in Node.js or in the browser. The repository is written in TypeScript and ships type definitions through the types field in package.json, so TypeScript consumers get declarations without a separate @types package. The README describes it as the fastest JSON validator for Node.js and browser, which is a claim about relative speed rather than a guarantee about your workload.

Compilation, Not Interpretation: How Ajv Turns Schemas into Functions

Ajv is not a loop that walks a schema and a value in parallel on every call. It generates source code for a function specific to that schema, and that function is what runs against each value. The repository layout shows the machinery: lib/ holds the TypeScript sources, and package.json builds with tsc into dist/, with the build script also copying lib/refs into the output and removing the TypeScript index files for the 2019-09 and 2020-12 reference schemas. The published package ships lib/ and dist/, not the sources you would edit.

Two schema languages are supported. JSON Schema drafts 04, 06, 07, 2019-09 and 2020-12 are the familiar vocabulary of type, properties, required and the rest. JSON Type Definition, standardised as RFC8927, is a narrower and more regular language. The documentation devotes a page to choosing between them, which tells you the project treats the choice as a real decision rather than a detail. JTD has no equivalent of the more open-ended JSON Schema keywords, so it is easier to reason about but expresses less.

Draft-04 is not in the core package. The README states that draft-04 support requires the ajv-draft-04 package. If your schemas were written years ago against that draft, you install a second package rather than getting it from ajv itself.

There is also a strict mode, documented on its own page, which changes which keywords and constructs Ajv accepts. That page exists because strict mode is the kind of setting that produces errors on schemas that previously worked, and the project chose to document it separately rather than bury it in the API reference.

Installing Ajv and Validating Your First Object

Ajv is published on npm as ajv. The README points to the getting started page on the project site for installation, and the package metadata confirms the entry points: main is dist/ajv.js and types is dist/ajv.d.ts. The repository's package.json lists a build script that runs tsc and copies lib/refs into dist/, and the published files array contains lib/ and dist/.

npm install ajv

That installs the package under the name ajv, which is the name field in package.json. The getting started guide on the Ajv website is where the project sends new users, so the exact import style and constructor options should be read there rather than assumed. What the package metadata does establish is what you import: the compiled entry at dist/ajv.js with declarations at dist/ajv.d.ts alongside it.

The repository also contains a .runkit_example.js file at its root, and that file is listed in the published files array. It is the project's own runnable example of the API, so it is the place to look for a working call sequence rather than reconstructing one from the prose documentation.

Ajv also ships a command line interface, documented at ajv-cli on the project site, which is useful when you want to check a schema or a data file outside a Node.js program. Compiling a schema once and reusing the resulting function is the point of the design; compiling inside a request handler throws that away.

Where Ajv Is the Wrong Choice

The first limitation is the one the project itself flags: security considerations have a dedicated page in the documentation. That page exists because compiling schemas means generating and executing code. A schema is not inert data in this design, and the documentation treats it as something to think about rather than something to ignore. If schemas come from users or from a plugin directory you do not control, read that page before you wire anything up.

The second is strict mode. Its separate documentation page implies a real failure mode: schemas that were accepted before can be rejected, and the error surfaces at compile time rather than at validation time. That is the correct place for it to surface, but it means upgrading Ajv is not always a drop-in change when your schemas use keywords the strict settings disallow.

The third is the schema language split. Choosing JSON Type Definition gives you a smaller, more predictable language and gives up the expressiveness of JSON Schema. Choosing JSON Schema gives you that expressiveness and the ambiguity that comes with union types, conditional keywords and the draft differences between 07 and 2020-12. The documentation has a page comparing the two precisely because this is not a decision Ajv can make for you.

Finally, Ajv validates. It does not parse, coerce or transform. If your incoming JSON has numbers encoded as strings and you want them converted, that is a separate step you write, and the schema will simply reject the value until you do.

Ajv and Zod: Compiled Schema Versus Inferred Types

The comparison people search for is Ajv against Zod, and the difference is where the source of truth lives.

With Ajv, the schema is a JSON document. It can be stored in a file, served over HTTP, generated by another tool, or shared with a service written in a different language that also understands JSON Schema. The TypeScript type is not derived from it; the package ships declarations for the Ajv API, not a type inferred from your particular schema. You either write the interface by hand or generate it separately.

With Zod, the schema is TypeScript code. The validator and the static type come from the same declaration, so changing the schema changes the type and the compiler catches the mismatch. That is a real advantage inside a TypeScript codebase. The cost is that the schema is not a portable document, and the validation is an interpreted call on a schema object rather than a function generated for that schema.

Neither property is universally better. If the schema has to be shared, versioned as data, or consumed outside JavaScript, Ajv's model fits. If the schema only ever exists to type your own code, Zod's model removes a duplication that Ajv leaves in place.

Maintenance, Licence and the Cost of Upgrading

The repository is not archived, and the last push was on 2026-09-06. The most recent release listed is v8.20.0 on 2026-04-24, preceded by v8.19.0 on the same day and v8.18.0 on 2026-02-14. That is a stable major line with point releases rather than a project in the middle of a rewrite.

The README says the maintainer is raising funds to develop and maintain Ajv once the next major version is released, and lists GitHub Sponsors and Open Collective as channels. Read that as a statement about the next major, not about the current one: v8 is the line you would install today, and the funding appeal is about what comes after it.

Upgrade cost is concentrated in two places. Strict mode can reject schemas that compiled before, so a version bump is a compile-time test of your schema set, not just a dependency swap. And draft-04 users carry an extra package, ajv-draft-04, which has to move in step with the core.

The licence is MIT, listed in the repository root as LICENSE. That is a permissive licence, and it is the same licence the npm package carries. This is a description of what the repository states, not legal advice; if your organisation has rules about which licences it accepts, that is a question for whoever owns those rules.

Editorial conclusion

Adopt Ajv when you already have JSON Schema documents, when you need draft-04 through 2020-12 support, or when validation runs on a hot path and you want a compiled function rather than an interpreted check. Do not adopt it if you want a TypeScript-first API where the type is inferred from the validator, or if you need a validator that also coerces and parses input rather than only checking it. Verify first that your schemas pass strict mode, since the documentation lists it as a distinct page and it changes which keywords are accepted, and confirm which schema language you are targeting, because draft-04 requires the separate ajv-draft-04 package rather than the main one.

Frequently asked questions

Official sources

1. ajv-validator/ajv on GitHub
2. License: MIT
3. Project website
4. README
5. Releases