API contract checks
Verify request and response payloads before integrating an API or shipping a client change.
Paste JSON data and a JSON Schema to verify required fields, data types, nested objects, arrays, enums, patterns and common numeric or string constraints. Use it to debug API payloads, configuration files and test fixtures before they reach production.
Paste the JSON document you want to validate into the JSON data field.
Paste the JSON Schema that describes the expected structure and constraints.
Select Validate against schema and review each error path before changing the payload or schema.
If the document cannot be parsed as JSON at all, fix the syntax first. Once parsing succeeds, schema validation answers the next question: does this otherwise valid JSON contain the fields, types and values the consuming system expects?
The following payload is valid JSON syntax, but it violates the example schema in three different ways: id is a string instead of an integer, the required email property is missing, and extra is not permitted because additionalProperties is false.
{
"id": "42",
"active": true,
"extra": "unexpected"
}$.id — expected integer, received string.
$.email — required property is missing.
$.extra — additional property is not allowed.
Verify request and response payloads before integrating an API or shipping a client change.
Check application, deployment, feature-flag and service configuration files against the structure your system expects.
Catch incorrect field types or missing required properties in mocked API responses and automated-test fixtures.
Separate malformed JSON syntax from structurally valid JSON that does not satisfy downstream contract requirements.
This browser implementation covers common JSON Schema constraints used in everyday API and configuration validation: type, required, properties, items, enum, pattern, minLength, maxLength, minimum, maximum, and additionalProperties: false.
Validation is recursive for nested objects and array items. Error messages include a JSON-style path such as $.user.email or $.roles[0] so you can identify the property that failed rather than only receiving a generic pass or fail result.
A normal JSON validator checks whether the text follows JSON syntax. Schema validation starts after parsing succeeds and checks whether the resulting data has the structure and values your system expects. Valid JSON can still fail because an id is a string instead of an integer or because a required field is missing.
This tool is intentionally not presented as a full standards-complete validator for every JSON Schema draft. Advanced keywords such as composition rules, references, conditional schemas, custom formats and draft-specific behavior may require a standards-complete library in your application or CI pipeline. Use this page for common structural checks and fast debugging.
A JSON Schema validator compares parsed JSON data with a schema that defines expected types, required properties, nested structures and other constraints. Valid JSON syntax can still fail schema validation.
No. This browser validator intentionally supports common everyday constraints such as type, required, properties, items, enum, pattern, string and numeric limits, and additionalProperties false. It is not a complete implementation of every JSON Schema draft or advanced keyword.
No. Validation runs locally in your browser. The JSON document and schema do not need to be uploaded to FixTools for this tool to work.
JSON syntax only proves that the text can be parsed. Schema validation can still fail when a field has the wrong type, a required property is missing, a value does not match a pattern or enum, or an unexpected property is present.
Fix the syntax first with the JSON validator or JSON error tools, then return to schema validation after the document parses successfully.
Move through the JSON problem with connected tools and references instead of treating formatting, parser errors, schema checks and API debugging as unrelated jobs.
Source-backed reference
Concise, standards-backed facts for developers working with JSON debugging and validation. Each claim is linked to the evidence registry and resolves to a primary standard or platform reference so it can be independently verified.
Trailing comma
{"a":1,}{"a":1}Single-quoted key
{'a':1}{"a":1}Unsupported literal
{"score":NaN}{"score":null}Direct answers are paired with source-specific evidence. This keeps technical claims independently verifiable and gives search and answer systems a clearer provenance trail than unsupported summary copy.