How to validate JSON in JavaScript (5 methods)

Validation means at least three different things in practice. It can mean: does this text parse at all; does it parse to the type my code expects; and does it contain the fields, types and value ranges my API contract promises. Conflating them is how a service ends up accepting a syntactically perfect document that then explodes three functions later on an undefined property.

Decide which question you are answering before choosing a technique. Untrusted input from a browser needs the third level. A config file you wrote yourself needs the first. Picking a heavier tool than the situation warrants costs you build weight and maintenance; picking a lighter one costs you production incidents.

The simplest approach wraps JSON.parse in a try-catch and treats a thrown SyntaxError as invalid. It is correct, it uses the engine's own compliant parser, and it costs nothing to write. Use it when you trust the source and only need a boolean answer.

Its weakness is error reporting. SyntaxError messages differ between V8, JavaScriptCore and SpiderMonkey, and rarely translate into something you can show a user. If a human has to act on the failure, you need either a parser that reports positions or a tool that does — which is what our JSON Validator exists for.

JSON.parse returns any valid JSON value, which since RFC 8259 includes bare strings, numbers, booleans and null. The literal text null parses successfully and gives you null; the text 42 gives you a number. If your handler assumes an object, both slip straight past a try-catch and fail later.

Add an explicit check after parsing: confirm the value is a non-null object, and confirm whether you expect an array or a plain object. Two extra lines eliminate an entire family of confusing downstream errors, and they cost nothing at runtime.

When you need to guarantee structure — required fields, correct types, enumerated values, numeric ranges, string formats — you need JSON Schema. Ajv is the standard implementation in the JavaScript ecosystem: it compiles a schema into a specialised validation function once, then runs it in microseconds per document.

The real benefit is that the schema becomes a shared artifact. The same file can validate inbound requests, generate TypeScript types, and document the endpoint. Alternatives such as Zod trade portability for a nicer developer experience and inferred types; if validation lives only inside one TypeScript codebase, that trade is usually worth it.

• Compile schemas once at startup, never per request.
• Enable strict mode so typos in your schema fail loudly instead of silently passing everything.
• Set additionalProperties to false on external inputs to reject unexpected fields.
• Return Ajv's error array to the caller — it names the exact failing path.

JSON.parse needs the entire document in memory, plus room for the resulting object graph — which in practice means several times the file size. Multi-gigabyte exports and log files will exhaust the heap before they finish parsing.

A streaming parser such as stream-json in Node.js reads the input incrementally and emits events as it goes, so syntax errors surface without full materialisation and per-record validation can run as records arrive. The pattern to reach for is a newline-delimited JSON file processed record by record, validating each with your compiled Ajv function.

For a one-off payload during debugging, none of the above is worth the setup. Paste the document into a client-side validator and read the error position. Our JSON Validator reports the failing line and column, and the JSON Formatter validates as it formats, so you fix the document and get a readable version in one step.

Because both run entirely in your browser, this is also the only category of online validator that is appropriate for a real production payload. A server-based formatter writes whatever you paste into someone else's request logs.

Debugging one payload by hand: use the browser tool. Parsing input you control in code: try-catch plus a type check. Accepting input from clients or third parties: compiled JSON Schema validation, with errors returned to the caller. Processing files larger than available memory: a streaming parser with per-record schema validation. In every case, validate at the boundary where data enters your system — never deeper.