Sort JSON Keys So the Diff Shows What Changed, Not What Moved

How to Use This Tool

Paste JSON and it comes back with every object's keys sorted, recursively. Arrays keep their order unless you ask otherwise, because array order is data.

Key order means nothing, until git looks at it

The JSON specification says an object is an unordered set of name-value pairs. Every parser agrees: two documents with the same keys in a different order parse to the same value.

Git does not parse JSON. It compares lines. So a tool that serialises keys in insertion order, or a language whose map iteration order varies between runs, produces diffs where most of the changed lines simply moved. The real change hides among them, and reviewers stop reading carefully — which is the actual cost.

Sorting keys before committing makes the diff show what changed. It is why lockfiles are sorted, why jq has --sort-keys, and why a lot of CI pipelines normalise config files before comparing them.

Arrays are not sorted, and should not be

An object's keys are unordered by definition. An array's elements are ordered by definition, and the order is usually meaningful: a list of middleware runs in sequence, a list of steps happens in order, a list of results came back ranked.

Sorting an array therefore changes what the document means, which is why it is off by default. The option exists for arrays that genuinely are sets — a list of tags, a list of allowed hosts — and it only touches arrays containing nothing but strings, since those are the ones that are usually sets.

Duplicate keys disappear

JSON permits duplicate keys and almost every parser keeps the last one. So {"a":1,"a":2} parses to {"a":2}, and re-serialising loses the first value with no error.

That matters when a file has been hand-edited or badly merged, because the duplicate is often the symptom you were trying to find. This tool counts them in your input and reports them before they are gone.

Which ordering to choose

• Natural — treats digit runs as numbers, so item2 comes before item10. Best for anything a human reads.
• Strict — compares by code point, which is what jq --sort-keys and most language sort functions do. Choose this if another tool in your pipeline will sort the same file, so the two agree.
• Case-insensitive — groups Name with name. Readable, and not reproducible across tools, so avoid it for anything committed.

If the point is reproducible diffs, consistency matters more than which order you pick — and strict is the one other tools will agree with.