Guide
JSON Syntax Validation vs JSON Schema Validation
Syntax answers whether text is JSON; schema validation answers whether the parsed value follows a declared contract.
This technical source review checks guide claims against current standards, official documentation, and the behavior of DevPouch tools. It is not an independent security audit.
Related tools
Problem and expected outcome
The payload `{"quantity":"many"}` is valid JSON but may be invalid for an API expecting an integer. Treating parsing success as contract validation lets type, required-property, range, and enum defects pass unnoticed.
Run syntax validation first because schema tools need a parsed instance. Then report schema paths separately from source syntax positions.
Debugging sequence
- Parse the document with a strict JSON parser.
- Select the schema version and the exact request or response schema for the operation.
- Validate required properties, types, formats, ranges, arrays, and additional-property rules.
- Report instance paths such as /items/0/quantity instead of only a generic failure.
- Test both accepted and rejected examples around every important constraint.
Synthetic example
{
"sku": "SYNTHETIC-42",
"quantity": "2"
}
Syntax: valid
Schema: invalid at /quantity; expected integerQA checks and boundaries
- A missing required field and an explicit null are tested separately.
- Numeric strings are not silently accepted unless coercion is documented.
- Unknown fields follow the additionalProperties policy.
- Schema-version differences are recorded.
Security and false assumptions
- A schema cannot prove business authorization or database state.
- Format checks vary between validators.
- Do not silently coerce production payloads just to satisfy a test.
Keep source errors and instance errors separate
A syntax error points into source text with a line and column. A schema error points into the parsed instance, commonly with a JSON Pointer such as /items/0/quantity, and may also point into the schema rule that failed. Mixing those locations makes reports difficult to act on.
Parse once and stop if syntax fails. After parsing, validate with the exact schema dialect and operation version. A draft mismatch can change how keywords such as exclusive bounds, nullable values, unevaluated properties, and formats are interpreted.
Coercion must be a product decision
Some server frameworks turn the string "2" into the number 2 before validation. That convenience changes the public contract and can differ between query, form, and JSON bodies. Tests should submit the same logical value through each supported transport and assert whether coercion is accepted.
If coercion is intentional, document the normalized response and failure behavior. If strict typing is expected, make sure a client library does not silently convert the fixture before it reaches the wire.
Schema boundary examples
- A required field omitted, present as null, and present with an empty value.
- Integer versus decimal versus numeric string.
- Known enum value, unknown value, and different casing.
- Additional property at root and in a nested item.
- Array with zero, one, maximum, and duplicate elements.
- Format-looking string whose semantic validity must be checked by application rules.
References
FAQ
What should be recorded when following this json syntax validation vs json schema validation workflow?
Record the synthetic input, observed status and headers, the smallest reproducible response, and the exact expectation that failed. Redact secrets before sharing evidence.
Can this checklist prove the production system is secure?
No. It supports repeatable debugging and testing; it is not a security audit or a substitute for system-specific authorization and threat analysis.