Does it remove zeros and false?

No. 0, false and an empty-string key name are values, not absences. Only null, empty strings, empty arrays and empty objects are considered empty, and each is separately switchable.

Is null different from a missing key?

To most consumers, yes — an explicit null says the producer knew about the field, an absent key says nothing. Removing nulls changes that meaning, which is why it is a choice rather than the only behaviour.

Are my files uploaded?

No. Everything runs in your browser.

Remove Empty Fields from JSONL

updated 16 August 2026

Serialisers that emit every field, populated or not, are why an export is three times the size it needs to be. Nulls, empty strings, empty arrays and empty objects carry no information and cost bytes on every line. This strips them at any depth, tells you which keys were empty most often — usually the interesting finding — and reports what the file weighed before and after.

Strip empties

Keep nulls Keep empty strings Keep empty arrays Keep empty objects Whitespace-only counts as empty Top level only Always keep these keys

Drop a .jsonl file here, or Up to 1 GB · in your browser

Input

Output

Emptiness is four different things

null is an explicit absence the producer wrote down. "" is usually a form field nobody filled in. [] and {} are containers a serialiser emitted because the schema said the key exists. Each is a separate switch because they carry different weight: dropping empty arrays is nearly always safe, dropping nulls sometimes is not — an ORM that distinguishes "set to null" from "not provided" will read the two differently on the way back in.

Removal is bottom-up, so a nested object whose every field was empty becomes empty itself and is then removed too. That cascade is what turns a deeply nested export into something readable, and it is also why top level only exists — turn it on when the nesting is meaningful and only the outermost record should be tidied.

Always keep these keys is the exception list, applied at every depth by name. Use it for a primary key that can legitimately be null, or a deleted_at whose absence and whose null mean different things. Note that 0, false and the string "0" are never treated as empty — they are values, and a tool that dropped them would be dangerous.

What the report tells you

The status bar names the keys removed most often. That list is a schema-drift report in disguise: a field empty on every record is a field nobody populates, either because the producer stopped writing it or because it was never implemented. Either way it is worth a question upstream, and often the right fix is to stop emitting it rather than to strip it here on every export.

The byte delta is the other half. Where the savings are large the cause is usually many keys rather than large ones; where they are small, the weight is in the values and Truncate or Gzip will do more.

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

Does it remove empty elements inside arrays?

It recurses into arrays and cleans the objects inside them, but it does not delete array elements — an array of three empty strings stays three elements long. Removing elements would change indexes and break anything positional.

Will the records still validate against my schema?

Only if the removed fields are optional. If a field is required, removing it when empty makes the record invalid — check with the Schema validator after stripping, and add the required fields to the keep list.

Is this the same as the minifier?

The Minifier removes whitespace between tokens and can drop keys you name. This removes keys based on their values, wherever they occur. They compose: strip empties, then minify.

Does key order survive?

Yes. Surviving keys stay in their original order, so a diff against the source shows only removals.