docs / 8 min read
JSON Validation Explained
JSON validation can mean syntax validation, schema validation, or business-rule validation. Each layer answers a different question about the payload and each layer is useful in a different stage of development or QA.
Syntax validation
Syntax validation confirms that JSON can be parsed. It catches broken quotes, commas, brackets, invalid values, and incomplete documents. This is the first step before formatting, comparison, or tree visualization.
Schema validation
Schema validation checks whether the payload has expected fields, types, and constraints. This is useful for API contracts because it can catch a string where a number is expected or a missing required object.
Assertion validation
Automation assertions verify business-critical fields such as status, amount, currency, role, permission flags, error codes, and inventory counts. These checks are often more focused than a full schema.
Choosing the right validation layer
Use syntax validation for basic correctness, schema validation for contract shape, and key path assertions for important behavior. Strong API tests usually combine all three.
QA example: Validate order response structure and business status
An order creation endpoint returns valid JSON, but the test still fails because order.status is submitted instead of confirmed and totals.tax is missing.
- Expected payload focus
- The JSON should parse successfully, include required totals fields, and return a confirmed order status.
- Actual issue found
- The payload is syntactically valid but fails business validation and is missing a required nested field.
Key paths to validate
- $.order.status
- $.order.totals.subtotal
- $.order.totals.tax
- $.order.totals.total
Automation assertion example
expect(response.order.status).toBe('confirmed');
expect(response.order.totals.tax).toEqual(expect.any(Number));
expect(response.order.totals.total).toBeGreaterThan(0);Practical checklist
- Parse the JSON before running any deeper validation.
- Use schema checks for required fields and expected types.
- Use key path assertions for values that affect business outcomes.
- Keep validation errors clear so failed tests explain what changed.
Developer and QA tips
- A payload can be valid JSON but still be wrong for the business scenario.
- Avoid asserting every field when the API includes dynamic metadata.
- Store important key paths alongside test cases so future maintainers understand the validation intent.
How JSON TreeDiff can help
Use the JSON comparison tool to review payload differences, switch to the tree viewer to inspect nested structures, and copy generated key paths into your API validation workflow. The tool runs in your browser and does not upload pasted JSON to a server.
Open the JSON tool