JSON Schema Generator

Turn sample JSON into a JSON Schema — with per-field control over types, required fields and constraints.

Paste one JSON document, an array of records, or several documents as JSON Lines. This tool infers the shape of your data, then lets you tighten it: override any field’s type, choose which fields are required, add string formats and bounds, promote repeated values to enums, and pick the schema draft (draft-04 through 2020-12). A built-in self-check validates every sample against the schema it just generated, so you always know the result actually fits your data. Already have a schema? Validate data against it with our JSON Schema Validator.

🔒 100% private — nothing is uploaded or stored. Parsing, type inference and schema generation all run locally in your browser with plain JavaScript. Your JSON never leaves your device — we don’t see, log or store it. The only way it gets out is when you copy the generated schema or download the .json file yourself.

Your sample JSON

Paste JSON Upload a file

Schema options

Field inspector

Every field the tool found, with its inferred type. Override a type, force a field to be required or optional, and add constraints — the schema on the right rewrites itself live. Constraints are offered for what your data actually is (string lengths and formats, numeric bounds, array rules).

Generated schema


        

            
            
        

    


    
    

        
How the inference works

        

            The tool walks your sample data as a tree. Each node accumulates everything it has seen:
            which types appeared, which object keys exist (and how often), string length ranges, and
            the distinct values observed. When you give it several samples — an array of records or
            JSON Lines — the same path is merged across all of them, so a field that appears in 2 of
            3 records becomes optional under the recommended present in every sample mode.
        

        
    
            
  • Types — if a field is a number in one sample and a string in another, the schema says "type": ["number", "string"]. Whole numbers are emitted as integer; mixed whole and decimal values as number.
    • 
            
  • Required — by default a property is required only if it was present in every sample object. You can flip any single field with the Required column, or change the global mode.
    • 
            
  • Formats — if all observed values of a string field match a known format (UUID, IPv4, date-time, date, time, email, URI), the tool adds format automatically. One outlier and it steps back — you can still force a format per field.
    • 
            
  • Enums — when a string field takes only a handful of distinct values (≤ 8), an enum toggle appears. Turn it on and the schema lists exactly those values, sorted.
    • 
            
  • Self-check — after every change the tool re-validates each original sample against the generated schema using the very keywords it emitted. If a row shows a type-mismatch chip, the self-check will show you the failing path too.
    • 
        

    


    

        
Required vs optional — the three modes

        

            
ModeBehaviourUse when…

            

                Present in every sample
                A property is listed in required only if it appeared in all sample objects.
                Your samples are representative of real data (the usual case).
            

            

                Every observed field
                Every key ever seen becomes required, even if it only appeared once.
                You want to lock the shape down hard and every sample had the full set of fields.
            

            

                None
                No required keyword at all — everything is optional.
                Your samples are sparse, or you only care about validating values that are present.
            

        

        

            Remember the JSON Schema default: a property that is not in required may be
            absent, but if it is present it must still match its schema. And with strict mode on,
            any key the schema doesn’t know about fails validation — that is what
            additionalProperties: false buys you.
        

    


    

        
Schema draft versions

        

            
DraftStatusNotes

            
draft-042007, legacyThe original. exclusiveMinimum/exclusiveMaximum are booleans that modify minimum/maximum.

            
draft-072014, widely deployedStill the most common version in the wild; many libraries default to it.

            
2019-09Current familyexclusiveMinimum/exclusiveMaximum become numbers; $defs replaces definitions.

            
2020-12LatestAdds prefixItems for positional array validation and is what new schemas should target.

        

        

            This tool emits the core keyword set — type, properties,
            required, items, enum, length and numeric bounds,
            additionalProperties — which is valid in every draft listed, so switching the
            $schema URI changes compatibility without changing the rest of the document.
        

    


    

        
Common pitfalls

        
    
            
  • Strict mode is a choice, not a default. JSON Schema without additionalProperties: false silently accepts unknown keys. Turn strict on when the schema guards an API boundary; leave it off for open data.
    • 
            
  • Integer vs number. If a field is 42 in your samples but can be 42.5 in production, override its type to number — an integer-typed schema will reject the decimal.
    • 
            
  • Enums go stale fast. An enum built from 3 samples breaks the day a fourth value ships. The tool only suggests enums for small, stable-looking value sets — use them for status codes and categories, not free-form data.
    • 
            
  • Patterns are ECMA-262 regular expressions, not PCRE: no lookaheads in older engines’ format-adjacent tooling, and escaping follows JavaScript rules. Test your pattern before trusting it at the boundary.
    • 
            
  • Absent is not null. A key missing from some samples does not add null to its type. If a field can genuinely be JSON null, override its type and include null via a type array in your own edit — inference only reports what it saw.
    • 
        

    






                    


                    
                    

                        
Suggested

                        

                            
                            
                                Tool
                                JSON Schema Validator
                                Validate JSON against a JSON Schema (draft-04 to 2020-12) with precise error paths, line/column locations & a schema health check
                            
                            
                            
                                Tool
                                JSON Formatter & Validator
                                Format, minify and validate JSON
                            
                            
                        

                    

                    

                    


                    

                        

                            
                                Luke Keam
                            
                            

                                Thank you for reading. Get in touch

                                Luke Keam | techgeek.biz