JSONL Field Coverage
See which fields are actually present, and in how many records. A per-field table with coverage percentage, missing and null counts, the types observed, distinct-value count, string length range and an example value. Fields with mixed types are flagged — they are the ones that break downstream loaders.
Profile
What the columns tell you
- coverage / present / missing — how many records have the key at all. Sparse fields are normal in event data and a warning sign in a dataset that should be uniform.
- nulls — present but null. Worth separating from missing: many consumers treat the two differently, and a field that is 100% present but 90% null is effectively empty.
- types — every JSON type observed, most frequent first. More than one gets a
← mixedmarker. - distinct — how many different values, up to the cap. A field with 2 distinct values across 50,000 records is a flag, not a value; one with a distinct value per record is an id.
- len — the min–max length range for string fields. A range of
3–48000in the same column usually means two different kinds of data share a key. - example — the first non-null value seen, truncated, so you can tell at a glance what the field holds.
What to do with the findings
- Near-duplicate field names —
user_idat 97% anduserIdat 3% means two producers disagree. Normalise with key case conversion. - Mixed types — decide the canonical type and coerce before loading. Find & replace handles simple cases; SQL playground handles the rest with a CAST.
- All-null fields — dead weight. Minifier strips them.
- Unexpectedly sparse required fields — the interesting finding. Formalise it with the Schema inferrer and enforce it with the Schema validator.
Privacy
Nothing is uploaded. The whole thing runs in this tab, in your own browser. That matters here more than on most tool sites — training data is usually the most sensitive file a team owns.
Frequently asked questions
How is this different from Stats?
Stats summarises the file — record count, size, overall type histogram. This is per-field: it answers "which keys exist, how often, and holding what", which is the question you have before loading data somewhere typed.
Why cap the distinct count?
Counting distinct values for a high-cardinality field means holding every value in memory. The cap keeps large files fast; anything over it is shown as >50, which is all you need to know that a field is not categorical.
Does it profile inside arrays?
No — an array is reported as type array. Element-level profiling needs a flattening decision that changes the meaning of "coverage"; use Flatten first if you want it.
Can I get this as CSV for a spreadsheet?
Yes, switch Output to CSV. JSON is also available if a script is consuming it.