Developer Tools

JSON Schema Validator for APIs and Configs

· QuickToolFlow
json json schema validation api developer tools

JSON tells you whether a document is syntactically valid. JSON Schema helps answer a different question: does this JSON have the shape your application expects?

Use the JSON Schema Validator when you want to check a sample payload against common schema rules. Use the JSON Formatter & Validator first when the raw JSON may contain syntax errors.

What JSON Schema Validation Checks

A schema describes allowed structure. It can say that the root value must be an object, that certain fields are required, that a value must be a string or integer, or that an array must contain items of a specific type.

A simple user schema might look like this:

{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string" },
    "roles": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}

This schema is not trying to describe every possible user field. It defines the fields that matter for a particular contract.

Start With a Minimal Contract

The best first schema is usually smaller than the full JSON sample. If the sample has 40 fields but your code depends on 8 of them, validate those 8 first.

This keeps the schema readable and makes failures meaningful. A schema that tries to describe every incidental field can become noisy, especially when APIs add metadata, tracking values, or experimental fields.

Start with:

  • the root type
  • required identifiers
  • required display or business fields
  • arrays your code loops through
  • enum values that affect branching logic

Then add stricter rules only when they prevent real defects.

Schema Validation vs JSON Parsing

Parsing checks whether the JSON text is valid:

  • Are strings quoted correctly?
  • Are commas in the right place?
  • Are arrays and objects closed?
  • Are values valid JSON values?

Schema validation happens after parsing. It checks whether the parsed value follows rules:

  • Is id an integer?
  • Is email present?
  • Is roles an array?
  • Are all role values strings?

That sequence matters. If the JSON cannot be parsed, schema validation cannot begin.

The Most Useful JSON Schema Keywords

type The type keyword is usually the first rule to add. Common values include object, array, string, number, integer, boolean, and null.

required The required keyword belongs on object schemas. It lists property names that must exist.

properties The properties object defines rules for named object fields.

items The items keyword defines rules for values inside an array.

enum and const Use enum when a value must be one of several known choices. Use const when a value must be exactly one value.

minimum, maximum, minLength, maxLength These rules are useful for numeric ranges and string length checks.

pattern The pattern keyword checks a string with a regular expression. It is useful for simple format checks, but it should not replace application-level validation for complex formats.

How to Debug Schema Errors

Good validation errors should point to a path. For example:

$.profile.age: expected integer, got string

That tells you the problem is not the whole document. It is the age field inside profile.

When a schema fails, debug in this order:

  1. Confirm the JSON parses.
  2. Check the path in the error message.
  3. Compare the actual value type with the schema type.
  4. Look for missing required fields.
  5. Reduce large payloads to the smallest failing example.

Small examples are easier to fix than full production responses.

Reading Error Paths

Schema errors are most useful when you read the path carefully. A path such as:

$.items[2].price

means the third item in the items array has a price problem. The schema may be correct, and the rest of the payload may be correct too. Do not rewrite the whole schema before checking the exact failing value.

For nested arrays, reduce the payload to only the failing item. This makes it easier to see whether the issue is a missing required field, a wrong type, or a rule that is too strict for real data.

Common Mistakes

Using required in the wrong place required only applies to object properties at the same schema level. If a nested object has required fields, put a required array inside that nested object schema.

Confusing integer and number An integer has no fractional part. 12 is an integer. 12.5 is a number but not an integer.

Expecting pattern to validate everything Regular expressions are useful, but formats such as email, URL, and date-time often have edge cases. Treat pattern checks as lightweight guards.

Forgetting additionalProperties If extra fields should not be allowed, use additionalProperties: false. If the API may add fields over time, avoid making schemas too strict.

Practical Workflow

Start with a representative JSON sample. Format it, then write a minimal schema that checks the contract you care about. Add more rules only when they protect real assumptions in your code.

A good schema is specific enough to catch mistakes but not so rigid that harmless API additions break every test.

Validation Before Conversion or Import

Schema validation is useful before data enters another system. If CSV data was converted into JSON, validate the JSON before importing it into an API. If YAML configuration was converted into JSON for testing, validate the JSON shape before deployment.

This catches problems such as:

  • string values where numbers are expected
  • empty arrays where at least one item is required
  • unknown status values
  • missing nested objects
  • typoed property names from spreadsheet headers

The earlier you validate, the easier the fix is. Once invalid data is imported into a database or sent to another service, cleanup usually becomes more expensive.

Keep going

Related tools and guides

All tools