b2KIT

JSON Schema Editor

Build and edit JSON Schema documents visually with type definitions, validations, and live preview.

Tested tool guide Tested browser tools Checked August 16, 2026

What JSON Schema Editor does and how it behaves

JSON Schema Editor assembles a schema document from visual choices about the root type, named properties, nested structures, and validation constraints. Each change appears in a live JSON preview, letting you inspect the keywords and hierarchy that describe acceptable JSON instances. It edits the contract, not the instance data. The most common surprise is that adding a field under `properties` does not make it mandatory; required property names must be declared separately on their containing object.

How the result is produced

1

Building the schema tree

The visual controls define a schema tree rather than an example data tree. Selecting an object creates an object schema; adding named fields places child schemas beneath `properties`. A field's selected JSON type and validation values become keywords on that child schema. The live preview lets you inspect the resulting nesting and keyword values as you edit.

2

Placing constraints

Requiredness is recorded at the parent object level. When a property is marked required, its name belongs in the parent's `required` array; it is not a flag inside the property's own schema. Array item rules belong under `items`, while string and numeric constraints remain on the schema node they constrain. Read the preview by following that hierarchy.

Good uses

  • Turning an API request or response field list into an object schema with explicit property types and required names.
  • Adding supported string, numeric, object, or array constraints while checking that each keyword appears on the intended schema node.
  • Reviewing the exact schema document created by visual edits before placing it in an API contract, configuration repository, or validation test.

Limits and checks

  • `properties` does not reject missing members. A name must also appear in the containing object's `required` array before its absence causes validation to fail.
  • Leaving `additionalProperties` unspecified does not close an object. Unlisted members remain allowed unless another applicable schema restricts them, so a property list is not automatically a whitelist.
  • The live preview is a schema artifact, not proof that a particular sample payload passes validation. Actual results also depend on the schema dialect and keyword support of the consuming validator.

Common questions

Does defining a property make it required?

No. A schema under `properties` constrains that member when it is present. To require it, include its exact name in the containing object's `required` array. Spelling and case must match. An optional field can therefore be fully typed and constrained while still being absent from a valid instance.

Will the preview work unchanged with every JSON Schema validator?

Not necessarily. Validators support particular JSON Schema drafts and vocabularies. A keyword from one dialect may be rejected or interpreted differently by a consumer configured for another. Check the `$schema` identifier, if present, and the validator's documented draft support. Also confirm whether that consumer treats `format` as an assertion or only as an annotation.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools