JSON Validation: catch broken data before it reaches your application

JSON is easy to produce and easy to break.

A missing comma can stop an API response from parsing. A single quote can turn an otherwise familiar object into invalid JSON. A duplicate key can parse successfully while leaving different tools to disagree about which value should win.

The problem is rarely finding out that something went wrong. The problem is finding the exact character that caused it.

DevFormat’s JSON validator checks JSON in your browser and points to the line and column where a syntax problem occurs. It can also flag duplicate keys, compare a document with an optional JSON Schema, and generate a test assertion from valid input.

What JSON validation checks

Valid JSON has a small, strict grammar. A validator checks that the document follows it before your application tries to consume the data.

The basic rules include:

• Objects use double-quoted keys and colon-separated values.
• Strings use double quotes, and control characters must be escaped.
• Arrays and objects must close in the right order.
• Numbers cannot contain invalid forms such as a leading zero in 01.
• Comments, trailing commas, and single-quoted strings are not part of JSON.

This is why a JavaScript object literal is not always valid JSON. JavaScript may accept comments, unquoted keys, or single quotes in some contexts. A JSON parser expects the stricter format used for data interchange.

The common mistakes

Most invalid documents fail for a handful of predictable reasons.

Missing commas

Every item in an object or array needs a comma before the next item:

{
  "name": "Ada"
  "role": "engineer"
}

The missing comma is easy to miss in a long response and will prevent the entire document from parsing.

Mismatched brackets or braces

Nested data must close in the reverse order in which it opened. An extra ], a missing }, or an object closed while an array is still open can invalidate the whole response.

Single quotes and unquoted keys

This looks reasonable in JavaScript, but it is not JSON:

{name: 'Ada'}

The JSON version is:

{"name":"Ada"}

Invalid numbers

JSON numbers use a restricted decimal form. Values such as 01, NaN, and Infinity need to be represented differently or rejected before the data crosses a system boundary.

Duplicate keys

Duplicate keys are a different kind of problem. A document may parse, but this is still unsafe:

{"status":"pending","status":"complete"}

Different parsers and downstream systems may keep the first value, keep the last value, or reject the document. DevFormat can flag duplicate keys as warnings so you can resolve the ambiguity before it becomes a data bug.

How to validate JSON with DevFormat

The basic workflow takes a few seconds:

1. Open the JSON validator.
2. Paste JSON into the editor or open a local .json file.
3. Read the status: valid JSON, invalid JSON, or valid JSON with warnings.
4. Follow the highlighted diagnostic to the reported line and column.
5. Fix the input and validate it again.

The validator runs as you edit, so you do not have to wait for a separate submission step. When the document is valid, the editor reports that no issues were found unless warnings need your attention.

Nothing is sent to a server for validation. The parser and diagnostics run locally in the browser, which is useful when the document contains internal data or credentials that should not leave your machine.

Read the error, not just the red highlight

An error location tells you where the parser stopped. The real mistake is sometimes a few characters earlier.

For example, if a parser points to the key after "Ada", check the previous value for a missing comma. If it points to a closing brace, check whether an object or array was opened earlier without a matching close.

The validator gives you the line, column, and a plain-English explanation. That combination is more useful than a generic “parse failed” message because it narrows the search while preserving the original input for inspection.

Check shape with a JSON Schema

Syntax validation answers, “Can this text be parsed as JSON?” It does not answer, “Is this the response my application expects?”

For that second question, paste an optional JSON Schema into the schema field. DevFormat first parses the document, then checks its shape with the schema. A document can therefore be valid JSON and still fail because a required property is missing, a value has the wrong type, or a nested field does not satisfy its constraints.

The tool reports the schema mismatch separately from a syntax error. That distinction matters: fixing a missing comma will not fix a response whose userId is a string when the contract requires a number.

Turn valid JSON into a test expectation

Once the document passes validation, DevFormat can generate an assertion from it. Choose a target such as Vitest, Jest, pytest, Go, or JUnit, then copy the generated snippet.

This is useful for turning a captured API response into a regression test. Review the generated value before committing it: remove fields that are intentionally variable, replace timestamps with matchers, and keep only the parts of the response your test actually owns.

Where validation fits in a workflow

Use a validator at the point where JSON changes hands:

• Before sending a request body to an API.
• After capturing a response while debugging an integration.
• Before committing configuration or fixture files.
• When checking a data export before importing it elsewhere.
• While writing a test for a nested response.

For a readable view of valid but deeply nested data, use the JSON viewer. For consistent indentation, use the JSON formatter. If the document is already malformed and you want help repairing mechanical mistakes, try JSON repair and validate the result afterward.

What validation cannot prove

Valid JSON is a starting point, not a guarantee that the data is correct. A document can have perfect syntax and still contain the wrong account ID, a stale timestamp, or a value that violates a business rule not represented in its schema.

Validation catches the structural problems early. Your application tests and domain checks still need to confirm that the values make sense.

The short version

Validate JSON before you debug the code that consumes it. Exact diagnostics help you fix syntax quickly; duplicate-key warnings prevent ambiguous data; schema checks verify the expected shape; generated assertions help turn a real response into a test.

When a JSON document refuses to parse, paste it into the DevFormat JSON validator and fix the reported problem at its source.