data / PRACTICAL GUIDE
JSON Formatting vs Validation
Separate readability, valid syntax, and the application rules your data must satisfy.
Formatting changes presentation. Syntax validation checks JSON grammar. Schema validation checks a defined structure and constraints. A payload can pass the first two and still be wrong for an application. Edit All checks syntax and flags duplicate keys; it does not validate a schema.
THE IDEA, VISUALLY
Readability and correctness are separate
- Format · Organize whitespace
- Validate · Check syntax
- Schema · Check structure
Three checks answer three questions
Formatting asks whether the JSON is comfortable to read. Syntax validation asks whether it follows JSON grammar. Schema validation asks whether its structure and values meet a particular contract.
A neatly indented object can still contain the wrong fields. A minified string can be valid and correct even though it is hard to read.
| Operation | Question | Example |
|---|---|---|
| Format | Can a person follow the nesting? | Indent an object |
| Validate syntax | Is this legal JSON? | Reject a trailing comma |
| Validate schema | Does it match a declared contract? | Require quantity to be an integer of at least 1 |
References: JSON Schema: what a schema checks
Valid syntax can describe invalid input
This is valid JSON syntax. An application may still reject a number as an email address or a negative purchase quantity. A syntax validator has no knowledge of those business rules.
Duplicate property names introduce another problem: parsers do not all handle them in the same way. Edit All flags duplicates without discarding either token. Decide which value was intended before sending the object.
{"email": 42, "quantity": -3}Common syntax mistakes
| Input problem | Why it fails |
|---|---|
| Single-quoted strings | JSON requires double quotes |
| Trailing comma | No element or property follows it |
| Unquoted property name | Keys must be strings |
| NaN or undefined | Neither is a JSON value |
| Literal newline inside a string | Control characters must be escaped |
References: RFC 8259: JSON grammar
Use a layered workflow
Validate syntax first. Resolve duplicate-key warnings. Format for human inspection. Then validate against a schema or test with the receiving application.
Do not automatically “fix” values that look unusual. A postal code may need leading zeroes and belong in a string; a large numeric identifier may require a string in the application contract even when its numeric JSON token is valid.
Frequently asked questions
Can valid JSON contain the wrong data?
Yes. A negative quantity or missing required field can be legal JSON yet fail the application’s rules. Syntax validation cannot infer that contract.
Does Edit All validate JSON Schema?
No. Use its validator for syntax and duplicate-key warnings. Apply a schema-aware validator separately when the receiving system provides a schema.