JSON Key Sorter

Sorting keys is one step towards a canonical form: a single representation that any equivalent document reduces to. This is why it is so effective before a comparison — two documents that mean the same thing become byte-identical rather than merely equivalent. Full canonicalisation goes further, fixing number formatting, string escaping, and whitespace as well, and it is what systems use when they need to hash or sign a JSON document. For everyday comparison work, sorting keys and applying consistent indentation gets you most of the benefit.

A diff is only useful in proportion to how much of it carries information. When a fifty-line change contains two real modifications and forty-eight reordered keys, reviewers stop reading carefully — and that is precisely when a genuine mistake slips through. Normalising order before comparing turns the diff back into a signal. The same logic applies to generated artefacts in a repository: if a tool emits keys in a nondeterministic order, sorting its output removes recurring churn that nobody should have to review.

Not to the specification — an object is an unordered set of name/value pairs, and two objects with the same pairs in different orders are semantically identical. In practice, order is preserved by most parsers and serialisers, which is why it shows up in diffs and in generated files at all. That combination is exactly why sorting is useful: the order carries no meaning, so normalising it is safe, and doing so removes a whole class of spurious difference.

Comparing two documents. When you have a response from staging and one from production, or a config before and after a change, an unsorted diff is dominated by keys that merely appear in a different position — and the one substantive difference is buried in noise. Sorting both files first makes the diff show only real changes. It is also the fastest way to check whether two API responses contain the same fields, which is otherwise surprisingly tedious.

Because array order is data. Unlike object keys, the position of an element in a JSON array is meaningful — it is the sequence of results a search returned, the steps of a workflow, the order a UI will render. Sorting an array would silently change what the document says. If you need array elements in a particular order, sort them by a specific field with a tool that understands the shape of your data, such as jq.

For generated files, yes — it makes diffs dramatically more useful and removes the churn caused by a tool emitting keys in a different order between runs. For hand-written config, it is a trade-off: alphabetical order is predictable, but a deliberate grouping can be more readable, and package.json in particular has a conventional field order that most developers expect. Sort what machines write; be more careful with what people write.

No. Every tool runs in your browser as JavaScript — your data is never uploaded, never logged, and never sent to a server. You can confirm it by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and seeing that everything still functions. That matters for JSON in particular, because API responses routinely contain personal data, tokens, and internal identifiers.