JSONL → JSON Schema
100% client-side. No upload.
Infer schema
JSONL → JSON Schema
Infer a JSON Schema (Draft-07) from a whole JSONL file at once. Picks up required fields, optional fields, union types from records that disagree, enum-like string columns, and numeric/length bounds.
What it infers
Most "schema from JSON" tools look at one record and guess. A JSONL file gives you many records — sometimes hundreds of thousands — so this tool walks every line and consolidates what it sees.
Required vs. optional
A property is marked required only if it appears in every record at the same nesting level. One record missing the key is enough to push it to optional. This matches how production data actually behaves: optional fields exist precisely because they aren't always present.
Union types
If a property is sometimes a string and sometimes a number — or sometimes null
— the schema records the union (e.g., ["string","number"]) instead of
picking one. Nullable fields get "null" appended automatically. No silent
coercion.
Integer vs. number
A field is reported as integer only if every observed value passes
Number.isInteger. The first floating-point value seen widens it to
number. This avoids the common mistake of generating an integer schema from
a sample that happens to contain only round numbers.
Enums
String fields with at most N distinct values across the whole file are
emitted as enum. The threshold is configurable above — set it to 0 to
disable enum detection entirely. The cap of 200 distinct values per field protects
against runaway memory on free-text columns.
Length and numeric ranges
Strings get observed minLength / maxLength; numbers get
observed minimum / maximum. These are hints based on what's in
your data, not authoritative constraints — adjust them by hand before publishing the
schema.
Tips & common pitfalls
- Sample size matters. Schemas inferred from 50 records will under-report optional fields. Aim for at least a few hundred records, more if your data has rare paths.
- Pre-validate the file. Bad lines are skipped with a warning, but if a corrupt section means you're inferring from half the file the schema will be too tight. Run the JSONL Validator first.
- Arrays are summarised, not enumerated. The schema's
itemsreflects the union of all element types ever seen, not per-position types. JSON Schema can do tuple-style item validation, but JSONL data rarely benefits from it. - Inferred is a starting point. The output is a faithful description of your sample; what you want as a contract may be tighter (drop optional fields you don't expose) or looser (allow types you haven't seen yet).
Example
Input:
{"id":1,"name":"alice","role":"admin","age":34}
{"id":2,"name":"bob","role":"user","age":29}
{"id":3,"name":"carol","role":"user"}Output (with enum threshold 10):
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"id": { "type": "integer", "minimum": 1, "maximum": 3 },
"name": { "type": "string", "enum": ["alice","bob","carol"], "minLength": 3, "maxLength": 5 },
"role": { "type": "string", "enum": ["admin","user"], "minLength": 4, "maxLength": 5 },
"age": { "type": "integer", "minimum": 29, "maximum": 34 }
},
"required": ["id","name","role"]
}
Note: age isn't required because record 3 omits it. role became
an enum because there are only two distinct values in the file.
Frequently asked questions
Which JSON Schema draft does it produce?
Draft-07. It's the most widely supported in tooling (Ajv, jsonschema, etc.) and the keywords used here have not changed in newer drafts, so the output is forward-compatible.
Can I infer from a JSON array instead?
Use JSONL ↔ JSON to convert in either direction first. The schema inferrer only walks JSONL lines.
Does it produce $defs / $ref for shared shapes?
No — every nested object is inlined. JSON Schema doesn't have a clean way to detect "the same shape used twice" automatically; if you need refs, refactor by hand once you have the inlined schema.
Is my data sent to a server?
Never. Inference happens in your browser. See the privacy policy.