Developer tools · JSON formatter & validator
Valid JSON vs valid against a schema: two meanings of 'valid'
· Background
json standards validation
A validator saying your JSON is valid means only that it parses. This post explains the levels of validity (syntax, structure, semantics) and why JSON Schema exists for everything beyond the grammar.
Valid, and still rejected
A request can be impeccable JSON and still be unacceptable to an API. `{"username":"nori","plan":"gold"}` has balanced delimiters, quoted names and legal values, yet a service may require an email, reject the plan name or forbid account creation in the current state. The parser and the application are answering different questions, so both results can be correct.
ToolAcre answers only the first question: can this text be parsed as strict JSON within its input limits? It does not load a schema, check required properties, verify formats, contact a database or evaluate business rules. When the tool says Valid, read that as “well-formed JSON syntax,” not as approval from the system that will consume the value.
Level one: well-formed syntax
Syntax validation checks the JSON grammar: one top-level value, correctly paired containers, quoted object names, valid commas and colons, legal strings, legal numbers and exact literals. It rejects `NaN` and `Infinity`, comments, trailing commas and single-quoted strings. It accepts any grammar-valid shape, including a lone number or an object with unfamiliar fields.
Malformed source has a textual failure point, so ToolAcre can report a line and column for the first impossible character. A missing comma may cause the next quote to be reported; a trailing comma may cause the closing delimiter to be reported. Fixing syntax creates a parseable value but does not establish that the value has the shape or meaning expected by another program.
Level two: the shape
Shape validation asks whether the parsed value matches a declared contract. A user schema might require `email`, constrain `age` to an integer at least 18, limit `tier` to `free` or `pro`, and disallow unknown properties. `{"email":false,"tier":"gold"}` is valid JSON syntax but fails those structural rules because the value types and allowed choices are wrong.
JSON Schema is one way to express such constraints, but ToolAcre does not execute it. A schema validator usually reports an instance path such as `/tier`, a keyword such as `enum`, and an explanatory message rather than a parser caret. Keep the schema version and API contract beside the payload when diagnosing this level; changing punctuation will not repair a correctly parsed value of the wrong shape.
Level three: meaning
Meaning depends on facts and rules beyond the document’s static shape. An `accountId` can have the correct string pattern while naming no account. A start date can match an ISO-style format while falling after the end date. A quantity can be positive yet exceed current stock. These failures require application context, stored state or relationships among fields.
Some semantic constraints can be approximated in a schema, but many belong in service logic where authoritative data and transaction state are available. Error responses at this level should identify the relevant field or rule without pretending the JSON text was malformed. ToolAcre cannot reproduce those decisions because it neither knows the contract nor sends the input to the application that owns the business rule.
Worked example: one payload through three checks
Start with `{"sku":"A-19","quantity":3,"warehouse":"north"}`. ToolAcre accepts it: all names and values follow JSON grammar. A schema can then require an object, a non-empty string SKU, a positive integer quantity and one of the documented warehouse codes. Suppose this payload passes those constraints too. Neither check has confirmed that SKU A-19 exists or that north holds three units.
The inventory service performs the third check against current records and may reject the request as unavailable. Changing indentation cannot alter that outcome. If `quantity` were written as `03`, syntax would fail first; if it were `"3"`, parsing would pass but the schema type check would fail; with numeric `3`, only the live stock rule remains. The same field can therefore fail at three distinct layers for three distinct reasons.
Where each check belongs
Run syntax validation as early as possible while editing, because later checks cannot operate reliably on text that does not parse. Enforce the declared shape at each untrusted application boundary rather than assuming a client already did so. Evaluate business invariants in the component that owns the required state, especially when the answer can change between requests.
Client-side checks improve feedback but do not replace server-side enforcement. Conversely, a server response saying “invalid JSON” should be reserved for parsing failure rather than used for every rejected request. Clear separation produces useful diagnostics: line and column for syntax, instance paths for structural constraints, and domain-specific codes or messages for semantic conflicts. ToolAcre supplies only the first category.
What this does not cover
This formatter does not author or evaluate JSON Schema, select a schema draft, resolve schema references, insert defaults or coerce strings into numbers. It also does not know an API’s OpenAPI document or custom validation conventions. Supplying a schema alongside the input would not change ToolAcre’s result because there is no schema-processing step in this tool.
Syntax validation also does not detect duplicate object names here; `JSON.parse` keeps the last occurrence before formatting. Nor does it guarantee numeric precision, canonical bytes, safe rendering or authorization. Each of those concerns needs its own contract and implementation. Avoid compressing them into a single green “valid” badge, because doing so hides which evidence was gathered and which questions were never asked.
Takeaway: 'valid' needs a qualifier
Qualify every validation claim. “Valid JSON” means the text follows the grammar. “Valid against this schema” means the parsed value satisfies a named structural contract. “Accepted by the service” means current application rules permit the operation. Passing one layer is necessary for the next in many workflows, but it is never evidence that all later layers passed.
Use ToolAcre to format and check strict syntax, including rejection of non-JSON literals such as `NaN` and `Infinity`. Then use the schema and application that actually govern the payload. When a request still fails, read the error at its own layer instead of repeatedly reformatting correct JSON. The tool has no schema checks, and that explicit boundary is more useful than an overbroad promise of validity.