A Draft 2020-12 JSON Schema for a Python project can be created from one strict, representative JSON value by using the JSON Schema Generator to infer structure, copying the output, and testing it with the exact Draft 2020-12-capable validator used in production. The generator handles structural inference locally in the current browser tab. Paste a representative strict JSON value, add an optional title, and generate a readable Draft 2020-12 schema rather than writing every property, type, null branch, and array-item rule manually. It infers observed object fields, nested objects, arrays, primitive types, nullability, and field presence, but it does not invent formats, ranges, enums, IDs, or a closed-object policy. Use one payload shape that captures the variations your Python application actually emits. A root array of several object records can reveal a field that is always present and another that is sometimes absent while still counting as one strict JSON value. Treat the copied result as a reviewable structural draft: required is based only on observed presence, open-object behavior is intentional, and business meaning still comes from documented requirements. The page does not upload data, run a validator, or contact a schema registry, so validation must happen afterward in your Python workflow.
Choose a Representative Strict JSON Sample
Start with data exported as strict JSON, not a Python dictionary written with comments, single-quoted keys, or a trailing comma. Although the resulting schema is intended for a Python project, the generator only accepts JSON syntax and will reject those non-JSON forms. A sample does not need every possible value, but it should reflect the fields, types, nesting, null patterns, and array contents that you want the first draft to describe.
A root object is useful when one record already contains the needed variations. A root array of object records is especially useful for required-field analysis because the generator can observe which properties appear in every object and which are missing from at least one. For example, an illustrative sample could contain id and email in every record, while nickname appears only in one. A nested settings object could contain theme in every record. That evidence supports a reviewable draft without pretending that the sample discovered an entire API contract.
Use the browser-based JSON Validator first if the source came from Python and you are unsure whether it is strict JSON. It checks JSON syntax and reports structural diagnostics before you spend time generating a schema from malformed input.
Generate a Python-Ready Draft 2020-12 Schema
Once the sample is ready, the generation workflow is short. The same draft can then be handed to the Python validation process, but the tool itself does not execute application code or a validator.
- Paste the representative strict JSON into the generator. Keep the entire intended sample in one value. If field presence varies, make the root value an array containing representative object records rather than adding multiple independent top-level values.
- Enter a concise schema title if one is useful. The title is optional. It can make the copied schema easier to recognize in version control or during review, but it does not replace descriptions, business names, or other documented requirements.
- Generate the schema. The output declares the Draft 2020-12 dialect with the URI https://json-schema.org/draft/2020-12/schema. Parsing and inference remain in the current tab, and boundary failures do not produce a partial schema.
- Inspect the object structure. Check that nested objects have properties, that each property is inferred with the observed type, and that only properties observed in every applicable object are listed in required. Property names are preserved exactly, including punctuation and prototype-shaped spellings.
- Review nullability and arrays. Look for null added alongside an object or item type. For a non-empty array, inspect the inferred items or anyOf branches. For an empty array, expect an empty items schema because the sample contains no element constraint that can be justified.
- Check the open-object decision. Confirm that additionalProperties is absent. This allows additional keys until your authoritative requirements call for a closed object, in which case the schema must be edited accordingly.
- Copy the result into your Python workflow. Give the schema to the Draft 2020-12-capable validator already used by your application, then test positive and negative instances with its production configuration and vocabulary.
Inspect the Inferred Structure
The generator makes deterministic observations from the sample, but the result still deserves a careful read. The following table separates the evidence in the JSON from the structural draft that can be supported.
| Observed sample evidence | Draft 2020-12 behavior | What to review |
|---|---|---|
| String, Boolean, null, safe integer, or another number | The corresponding JSON Schema type is emitted. | Confirm that the value is not being used as an identifier or precision-sensitive decimal that should be represented and validated as a string. |
| Compatible numbers, such as integer and number | Integer widens to number. | Confirm that accepting both numeric forms matches the application contract. |
| Incompatible observed types | Deterministic anyOf branches represent the evidence. | Check branch order and remove a branch only when requirements justify doing so. |
| Null combined with a directly typed object or item | Null is added to the type array while the properties or items are retained. | Verify that absence is genuinely nullable rather than a separate error case. |
| Array with one or more observed elements | Items are inferred from every observed element, including mixed evidence. | Test each observed item shape and combinations of those shapes. |
| Empty array | An empty items schema is emitted. | Decide from requirements whether every JSON item type is allowed or the schema needs a stricter items rule. |
| Property missing from at least one applicable object | It is not included in required. | Do not interpret absence from required as a complete statement about business optionality. |
| An object containing only observed properties | Objects remain open because additionalProperties is omitted. | Add a closed-object policy only if unseen keys must be rejected. |
Nested objects and arrays are inferred recursively, so the same decisions can appear at several levels. Duplicate equivalent branches are removed, and output order is deterministic. Reusing the same strict input therefore produces stable text that can be reviewed and committed, which makes later changes easier to inspect.
Complete the Schema From Authoritative Requirements
A generated structural draft intentionally does not claim that one example reveals every semantic rule. It does not infer format, pattern, enum, const, minimum, maximum, multipleOf, length limits, uniqueness, descriptions, defaults, examples, deprecation, readOnly, writeOnly, content encoding, references, anchors, IDs, conditional logic, unevaluated properties, or business meaning. These omissions are limitations by design: adding a precise constraint from a spelling, label, or small sample can create a stricter rule than the application can support.
Review those items against documentation, protocol definitions, and code that already performs authoritative validation. For example, a string may look like an email address, but that observation alone is not enough to generate a format constraint. Likewise, a sample containing one or two category values is not evidence for an enum. Add only the constraints that those requirements actually demand. The JSON Schema 2020-12 core specification provides the standardized vocabulary to consult when deciding how an authoritative rule should be expressed.
Format requires extra caution. Draft 2020-12 does not guarantee that every implementation asserts format violations; behavior can depend on the chosen vocabulary and validator configuration. Confirm the exact implementation and settings used in production instead of assuming that two libraries provide identical keyword behavior.
Test the Copied Schema in Your Python Workflow
Pass the copied schema to the Draft 2020-12-capable validator selected for the Python project. The generator is not a validator, so success at generation time means only that strict JSON was parsed and structural output was produced. It does not prove that the draft matches your application rules, and it does not test an instance against the schema.
Use a focused test matrix with both accepted and rejected documents. Your matrix should include the representative structure, a required field omitted, an incorrect primitive type, a null where the value is not nullable, and an invalid array item. Add checks for a valid anyOf branch, an invalid anyOf branch, and an object containing an unobserved key. For nested structures, repeat the same checks at each level where the corresponding rule is present.
| Validation case | Positive document | Negative document |
|---|---|---|
| Required field | Include a field observed in every applicable object. | Omit a field listed in required. |
| Nullability | Use null when the generated type array explicitly permits it. | Use null when the structure is directly typed without null. |
| Primitive type | Supply a value matching the inferred string, integer, number, Boolean, or null type. | Supply a different JSON type where it is not accepted. |
| Array items | Provide an item matching the inferred items schema or an observed anyOf branch. | Provide an item outside the inferred type or branches. |
| Open object | Include a new key when the sample has not established a closed-object policy. | Reject an unobserved key only after authoritative requirements add that policy. |
Run the final checks with the same validator, configuration, and vocabulary used in production. A Draft 2020-12 label alone is not enough to guarantee identical implementation behavior. If the generated draft passes the original sample but fails to express a documented rule, edit the schema from that requirement and repeat the complete positive-and-negative test set.
Handle Invalid or Oversized Samples Safely
Strict JSON is required. Comments, trailing commas, NaN, Infinity, undefined, BigInt, and JavaScript literals fail rather than being silently repaired. This matters when copying a Python-oriented draft: a syntactically convenient Python object is not automatically strict JSON. Convert the intended sample to strict JSON first, then let the generator process that value.
Number handling also deserves attention. JavaScript parses the sample number before inference. Only safe integers become JSON Schema integers; other numbers become number values, avoiding a false exactness claim for larger rounded values. For precision-sensitive decimals or identifiers, a string may be the safer representation, with application-level validation supplying the authoritative rules.
The generator has fixed boundaries. It accepts up to 500,000 input characters, 50,000 values, 40 nesting levels, and 1,000,000 output characters. A boundary failure produces no partial schema. If a limit is exceeded, reduce the sample or simplify the intended output rather than assuming that generation completed with a truncated result.
For a deeper look, see JSON to CSV API Alternative That Runs Locally in Browser.
For a deeper look, see Convert JSON to an Excel Table Without Uploading It.