JSON Schema Generator

Treat inference as a starting point

A JSON sample shows values that happened once; it does not describe every valid future document. The generator can infer object, array, string, number, integer, boolean, and null shapes, then nest those shapes to match the sample. It cannot know business rules such as minimum lengths, numeric ranges, formats, descriptions, defaults, conditional requirements, or whether a field omitted from another response is optional. Review the output before using it as a contract.

Required properties need human review

Every property visible in the sample is added to required. That conservative choice catches missing data when the sample represents the complete contract, but it overstates requirements when the payload is only one example. Remove truly optional names from required while leaving their schemas under properties. A required property may still accept null if its schema allows null; presence and nullability are separate decisions.

Arrays reveal only observed items

A non-empty array lets the generator inspect its elements. Mixed observed shapes produce an anyOf starting point, while an empty array provides no evidence about item type. Real arrays may contain more variants than one payload exposes. Collect representative examples from successful, empty, error, and edge-case responses, then merge the intended rules manually instead of assuming the first record is complete.

Add contract meaning after generation

Useful production schemas often need minLength, pattern, format, enum, numeric boundaries, array limits, reusable definitions, and a deliberate additionalProperties policy. Add titles and descriptions that explain domain meaning rather than restating field names. Avoid deriving sensitive examples or secrets into documentation. Choose the schema draft and vocabulary supported by the validators, code generators, API gateway, and documentation tools in your actual pipeline.

Validate several positive and negative examples

Send the generated result to JSON Schema Validator, then test more than the original sample. Positive cases should cover optional fields and boundary values. Negative cases should omit required properties, use wrong types, exceed limits, and include unexpected fields when those should be rejected. A schema that accepts only its generating sample is not yet a useful interoperability contract.

Evolve schemas deliberately

Once consumers depend on a schema, changing it can be breaking even when the new version validates a fresh sample. Adding a required property, narrowing a type or range, removing an enum value, or forbidding previously accepted properties can reject existing payloads. Review schema changes with JSON Diff and test representative consumer fixtures. Generation and editing happen locally in this tab; the sample is not uploaded to Cryonel.