The pull request had 240 changed lines and I had touched exactly two values. That was the moment I got serious about sorting JSON keys. A teammate had run a config file through a formatter that reordered its keys, I had edited two of those values by hand, and the resulting diff was an unreadable wall of red and green where 238 of the lines were keys that had simply moved. My reviewer, understandably, asked me to redo it. The real changes were invisible inside the noise.
I run toolz.dev and also build Laravel and WordPress projects, which means I live inside package.json, composer.json, tsconfig.json, translation catalogs, and a hundred other JSON files that get committed to version control. A JSON file with unpredictable key order is a small, recurring tax on every one of those. Sorting keys into a stable alphabetical order is the fix, and it is one of those changes that looks cosmetic until the first time it saves you a wasted code review. This guide covers when to sort JSON keys, when not to, and how to do it without breaking anything.
TL;DR: A JSON sorter reorders an object's keys into alphabetical order and re-serializes the result. Key order does not change what JSON means, because objects are unordered by the JSON standard, but a consistent order makes files readable and produces clean version-control diffs that show only changed values. Sort recursively to reach nested objects, keep array order by default because arrays are ordered, and choose ascending or descending, pretty or minified output. The JSON Sorter runs entirely in your browser.
What is a JSON sorter?
A JSON sorter takes a JSON object and rearranges its keys into alphabetical order, then writes the object back out. The values are untouched. Only the sequence in which the keys appear changes, and that is safe because RFC 8259 defines an object as an unordered collection: reordering keys cannot change what the document means. So {"name":"toolz","author":"Liton"} becomes {"author":"Liton","name":"toolz"}. By default the sort is recursive, which means the keys inside every nested object are sorted too, all the way down to the deepest level.
That is the whole operation, and its simplicity is the point. You are not transforming data, validating a schema, or converting a format. You are imposing a predictable order on something that had an arbitrary one. Every other benefit, readability, comparability, clean diffs, flows from that single predictable ordering.
Does sorting keys change what my JSON means?
No, and this is the fact that makes sorting safe. In the JSON standard, ECMA-404, an object is defined as an unordered collection of name and value pairs. The specification is explicit that the order of those pairs is not significant. Any conforming parser reads {"a":1,"b":2} and {"b":2,"a":1} as exactly the same data. When your program does config.timeout or data["name"], it looks the key up by name; it never cares where in the object that key was written.
There is one caveat worth stating clearly, because someone always asks. A tiny number of systems abuse JSON objects as if they were ordered, relying on insertion order for display or processing. That is a misuse of the format rather than a property of it, but if you are feeding a system you do not control, test before you commit a sorted file into a pipeline you cannot inspect. For the overwhelming majority of real-world JSON, config files, API payloads, lock files, translation catalogs, sorting keys is a purely presentational change with zero effect on meaning.
Arrays are the opposite case, and the distinction matters. A JSON array is ordered by definition, and its order frequently carries meaning: a sequence of steps, a ranked list, a set of coordinates where position one is longitude and position two is latitude. Reordering an array can silently change what the data says. That is why this tool preserves array order by default and only sorts arrays when you explicitly ask it to, and even then only for arrays whose elements are all strings or all numbers.
Why would I sort JSON keys?
The headline reason is clean diffs, and it is the one that changed how I work. Version-control tools compare files line by line. When two files that represent the same data write their keys in different orders, the diff is full of keys that moved rather than values that changed. Adopt a rule that every JSON file is written with sorted keys, and the problem disappears: two versions of the file differ only where a value actually differs, so a reviewer sees the real change immediately. This is exactly why many linters and formatters offer a sort-keys option, and why tools like jq ship a sort-keys flag.
The second reason is human readability. When you are scanning a large configuration file looking for a specific setting, alphabetical order tells you where to look. You do not read the whole file; you jump to roughly where the key should be, the way you would in a dictionary. On a file with eighty keys, that is the difference between a two-second lookup and a full scan.
The third reason is comparability across files. If your project has ten JSON files that should all share a common structure, sorting them all the same way makes it trivial to eyeball whether one is missing a key or has an extra one. Divergences line up next to each other instead of hiding in different positions.
The fourth reason is canonicalization. Some workflows need a stable, deterministic representation of a JSON value, for example to hash it, cache it, or compare two payloads for equality regardless of how they were serialized. Sorting keys is one step toward a canonical form, though a full canonical JSON also normalizes whitespace and number formatting.
How do I use the JSON Sorter?
Paste your JSON into the input box on the JSON Sorter, or load the sample to see the shape of the output. The input must be valid JSON. If it is not, the tool reports the parse error with its position so you can fix a stray comma or an unclosed bracket before sorting.
Then choose how the sort runs. Pick ascending, which is A to Z, or descending for Z to A. Decide whether to fold case, which is on by default so that Name, name, and NAME sit together rather than being separated because uppercase letters sort before lowercase ones in raw character order. Choose whether to descend into nested objects, which you almost always want, or to sort only the top level. If you want arrays of strings or numbers ordered as well, turn on array sorting; mixed arrays and arrays of objects are always left as they are.
Finally, pick your output style. Pretty-print with two-space, four-space, or tab indentation for a readable file you will commit, or minify to a single line for the smallest payload for storage or transport. Run the sort, then copy the result or download it. The key count tells you how many keys were reordered, which is a quick sanity check that the tool saw the structure you expected.
Ascending, descending, recursive: which settings do I want?
Most of the time the defaults are what you want: ascending, recursive, case-insensitive, pretty-printed with two spaces. That produces the readable, diff-friendly file that motivates sorting in the first place. The other settings exist for specific situations, and the table below is how I decide.
| Setting | Default | When to change it |
|---|---|---|
| Order | Ascending (A to Z) | Descending is rare; useful when you want the most recent or highest-priority keys, named to sort last, at the top |
| Recursive | On | Turn off only when you want to reorder top-level sections but preserve the hand-tuned order inside each one |
| Ignore case | On | Turn off when you need strict code-point order, for example to match another tool that sorts case-sensitively |
| Sort arrays | Off | Turn on for arrays that are genuinely unordered sets, like a list of tags or allowed values |
| Pretty print | On | Turn off to minify for transport or storage |
The one setting people misuse is array sorting. Turn it on only when you are certain an array represents an unordered set. A list of tags, a set of permitted file extensions, or a bag of feature flags is safe to sort. A list of pipeline steps, a route table, or anything where position implies sequence is not. When in doubt, leave arrays alone, because the tool's default of preserving order can never corrupt your data, while sorting the wrong array silently can.
How does this fit with other JSON tools?
Sorting is usually one step in a small chain. When JSON arrives minified and unreadable from an API, I run it through the JSON formatter first to indent and validate it, then sort the keys to make it scannable. When I am preparing a payload for transport after sorting, the JSON minifier strips it back down to a single line, and because the keys are already sorted, two minified payloads that represent the same data come out byte-for-byte identical, which is handy for caching and comparison.
For structural work rather than presentation, the JSON flattener turns nested objects into dotted keys and back, which pairs naturally with sorting when you are wrangling config into environment variables. And when you need the data in another format entirely, the JSON to YAML converter is the next stop; sorting keys before converting gives you a YAML file with a predictable, readable field order too. If you want the bigger picture of how these fit together, I laid out my full setup in the web developer toolkit guide, and the deeper mechanics of formatting live in the JSON formatter guide.
A real example: taming a package.json diff
Let me walk through the exact situation that started this article, because it shows why the setting choices matter. I had a package.json where the dependencies block had been written in install order, roughly the order in which packages had been added over two years. A new team member ran their editor's format-on-save, which sorted the dependency keys, and committed it alongside a genuine change: bumping one package from version 4 to version 5.
The diff was a disaster. Every dependency below the bumped one appeared to have moved, because sorting had shifted their positions, so the reviewer saw thirty changed lines for what was a one-line upgrade. The fix was not to argue about whose editor was right. The fix was to sort the file once, commit that sort as its own separate change with a message like "sort package.json keys," and then make the version bump on top of the now-stable order. After that, every future dependency change produced a clean one-line or two-line diff, because the file was already in the order everyone's tools wanted to put it in.
That is the pattern I now follow for any JSON that lives in version control. Sort it once in a dedicated commit, then keep it sorted. The JSON Sorter with its defaults, ascending and recursive, produces exactly the order that Prettier's sort option and jq --sort-keys produce, so the file stays stable no matter which tool a teammate happens to run. The one thing I check first is arrays: package.json has no meaningful arrays to worry about, but a file with an ordered array like a list of build steps needs array sorting left off, which is the default, so the sequence survives.
Which tools and formats sort JSON keys?
Sorting JSON keys is a common enough need that it shows up across the ecosystem, which is a good sign the practice is sound rather than a personal quirk. The command-line processor jq has a --sort-keys flag, often written -S, that sorts the keys of every object in its output. The Prettier code formatter can sort keys in JSON through its configuration. Many linters offer a sort-keys rule that flags unsorted objects in source code. Language standard libraries expose the same capability, for example Python's json.dumps accepts a sort_keys=True argument that produces canonical, sorted output.
What a browser-based sorter adds is the quick, no-setup case. When you have a blob of JSON from an API response, a log line, or a Slack message, and you just want to read it in a sane order right now, opening a page and pasting is faster than wiring up a formatter or dropping into a shell. It is the same reason a paste-and-go formatter exists alongside editor plugins: the tool meets the ad-hoc need that the configured pipeline does not cover.
Is my JSON private?
Yes. The JSON is parsed, sorted, and re-serialized entirely in your browser using JavaScript. Nothing is uploaded to a server, logged, or stored anywhere. That is not a minor detail for JSON specifically, because JSON is where secrets live: API responses carrying tokens, config files with connection strings, payloads containing customer records. Pasting any of that into a tool that ships it to a server is a real risk, and it is exactly the risk this tool is built to avoid.
You can verify the claim the same way I would. Open the network tab in your browser's developer tools and watch it while you sort; no request leaves the page. Or disconnect from the internet and keep sorting, because once the page has loaded, the tool works with no connection at all. Client-side processing is the default for everything I build, and if you care about the wider argument for it, the data privacy guide makes the case in full.
Frequently asked questions
What does it mean to sort JSON keys?
Sorting JSON keys reorders the name-value pairs of an object into alphabetical order without changing any values. The object {"name":"toolz","author":"Liton"} becomes {"author":"Liton","name":"toolz"}. Only the order of the keys changes, so the data the document represents stays exactly the same.
Does sorting keys change what my JSON means?
No. In the JSON standard, ECMA-404, an object is an unordered set of name-value pairs, so reordering its keys does not change its meaning. Any conforming parser reads the sorted and unsorted versions as the same data. The order matters only for human readability and for producing stable diffs.
Are nested objects sorted too?
Yes, by default. Recursive sorting is on, so the keys of every object inside the document are sorted, at every level of nesting. You can turn recursion off to sort only the top-level keys and leave nested objects in their original order.
Does the sorter reorder arrays?
Not by default. Arrays are ordered by definition, and reordering them can change meaning, so the tool preserves array order. There is an option to sort arrays whose elements are all strings or all numbers when you do want them ordered; arrays that mix types or contain objects are always left as they are.
Why would I sort JSON keys?
The most common reason is stable diffs: when every file writes its keys in the same alphabetical order, version-control diffs highlight only the values that changed rather than keys that moved. Sorting also makes large config files and API responses far easier to scan and compare by eye.
How does case-insensitive sorting work?
With case-insensitive sorting on, keys are compared as if lowercased, so Name, name, and NAME are grouped next to each other instead of being separated because uppercase letters sort before lowercase ones in raw character order. Turn it off to sort strictly by character code point.
Can I minify the sorted JSON?
Yes. Choose minified output to get the sorted JSON on a single line with no extra whitespace, which is the smallest form for storage or transport. For a readable file, choose pretty output with two-space, four-space, or tab indentation instead.
Is my JSON uploaded anywhere?
No. The JSON is parsed and sorted by JavaScript in your browser and is never transmitted, logged, or stored. You can verify this by watching the network tab while sorting, or by going offline, the tool keeps working without a connection.
Written by Liton, builder of toolz.dev. I build browser-based developer tools and write about working with JSON, Laravel, and the web.
