Valid JSON, rejected API request - where a formatter stops
Why a JSON formatter catches syntax but does not validate required fields, field types or API business rules. When to use JSON Schema, OpenAPI or Zod.
The payload is nicely indented, the formatter says "valid JSON", and the endpoint still returns 400 Bad Request. Annoying, but fair. The API did not promise to accept every syntactically correct JSON document.
JSON formatter solves a narrow problem: parse a string as JSON, show parser errors, add indentation or remove whitespace. It is a fast way to catch a trailing comma, a missing quote or a comment copied from a JavaScript object literal.
It does not know your API contract.
What the formatter checks
If a document passes JSON.parse, its syntax is valid: double-quoted strings, commas in the right places, valid numbers, closed objects and arrays. For reading logs, inspecting an API response or cleaning a request body from an issue, that is often enough.
This payload is syntactically valid:
{
"email": "user@example.com",
"age": "42",
"status": "enabled"
}
The parser is happy. Your API may not be: age might need to be a number, status might only allow active | blocked, and profileId might be required. Valid JSON, invalid request.
What schema validation checks
Schema validation answers a different question: does this structure match the contract? That is where required fields, types, string length, enum values, date formats, nested objects and arrays belong.
Use JSON Schema, an OpenAPI validator, Zod, Yup or backend validation for that. These tools do not replace a formatter; they sit one level above it. The formatter makes the document readable and syntactically clean. The schema checks whether it means the right thing for a specific API.
Fast 400 diagnosis
| Symptom | Check |
|---|---|
Unexpected token in the formatter | JSON syntax |
API says field is required | Endpoint contract |
API says must be number | Field type |
API says unknown enum value | Allowed values |
| Works in dev, fails in prod | Schema version or feature flag |
If the formatter reports the error, fix the JSON. If the API reports the error, open the contract: Swagger, OpenAPI spec, JSON Schema in the repo, DTO class, handler tests. Pretty indentation will not help anymore.
Where devdeck helps
First paste the payload into JSON formatter. If it does not parse, it is not ready for the API. Fix the syntax, copy the formatted version, then compare it with the contract.
If the payload contains secrets, tokens or internal ids, check the Network tab: the devdeck formatter runs in the browser, and the source payload should not be uploaded to a server. For very large JSON documents that make the tab pause for seconds, use jq or a local test fixture.
The practical workflow is two steps: formatter for grammar, schema validator for the contract. Reverse the order and you can spend a lot of time arguing that a string containing a number is basically a number.
Questions
Does the JSON formatter validate JSON Schema?
No. The devdeck JSON formatter checks JSON syntax and formats the document. Schema validation needs a separate tool or code-level validator.
Why does JSON.parse pass while the API returns 400?
Because JSON.parse checks JSON grammar only. The API can require specific fields, types, enum values, date formats or relationships between fields.
Can I trust a formatter before sending a production payload?
A formatter is useful as a quick syntax filter. Production payloads need a contract: JSON Schema, OpenAPI, Zod, Yup or a test near the code.