Paste the original document into the left editor and the updated one into the right, then press Compare JSON. Both sides are parsed and rewritten into the same canonical form before anything is compared, so what you see highlighted is a difference in the data rather than a difference in how it was written. Removed content is marked in red on the left, added content in green on the right, with line numbers to find each change in your own file.
JSON objects are unordered by definition — RFC 8259 gives no meaning to the position of a member — but almost every diff tool compares the text and reports a moved key as a deletion plus an insertion. Serialisers reorder freely: a Go map iterates randomly, a schema migration rewrites a config, a formatter sorts alphabetically. This tool sorts every object key on both sides first, recursively, so two documents holding identical data compare as identical no matter what order they were written in.
{"b":2,"a":1} vs {"a":1,"b":2}no differences
Arrays are left exactly as they are, and that is deliberate rather than an omission. A JSON array is ordered, so moving an element is a real change to the data: the second item in a list of pipeline stages runs second, and a reordered array of route rules matches differently. Sorting arrays to make diffs quieter would hide exactly the changes most likely to break something. If an array in your data is genuinely a set, sort it on both sides before pasting.
{"tags":["a","b"]} vs {"tags":["b","a"]}reported as a change
A minified payload and a pretty-printed one are the same document to this tool. Both are reparsed and re-emitted with two-space indentation, so a file that arrived on a single line from an API can be compared directly against the formatted copy in your repository without reformatting either by hand first. The same normalisation settles number literals and string escapes: 1.0 and 1 are the same number, 1e3 and 1000 are the same number, and a needlessly escaped character compares equal to its plain form.
The usual reasons to open a JSON diff are checking what an API started returning after a deploy, working out which key in a Kubernetes or Terraform state file changed between two environments, updating a test fixture and wanting to know whether the update was intentional, and reviewing a package-lock or composer-lock that a tool rewrote wholesale. All four are cases where formatting noise ordinarily buries the two lines that matter, which is the specific problem canonicalising both sides solves.
If one side contains the same key twice, the parser keeps the last occurrence and the earlier one disappears from the comparison. That follows how virtually every JSON parser behaves, including the one your application uses, so the diff shows you what your code would actually see. It does mean a duplicate key is not itself reported as a difference — if you need to catch that, validate the document in the JSON tools first, where the raw text is what gets checked.
Above the comparison is a summary of what actually changed, sorted into the three questions people bring to a JSON diff: which properties are missing from one side, which changed type, and which changed value. Each one is listed at its own path — $.scripts.test, $.items[2].id — with the old and new value beside it. The counts double as filters, so a diff dominated by one kind can be read by switching the other two off. This is the part a line-based diff cannot give you: a line number tells you where the text moved, a path tells you what the data means.
If either document is not valid JSON, the tool names the side and the position — Original: Line 4, column 15 — Unexpected token — and then compares both sides as plain text so you can still see what differs. The location is worked out from the JSON grammar rather than from the browser’s error message, which matters because the common breakages (a trailing comma, single quotes, True instead of true) are exactly the ones most engines report without any position at all. The text fallback is all-or-nothing on purpose: normalising only the side that parses would compare a reformatted document against a raw one and mark almost every line as changed.
Split view puts the two documents side by side; unified view interleaves them into one column in the style of a git diff. The statistics panel counts changes as words or characters and again as lines added, removed and modified. In a long document the differences are rarely adjacent, so the up and down arrows step between them with a counter showing which change you are on, and the keyboard does the same with the arrow keys or j and k. The result can be copied to the clipboard or downloaded as a text file for a ticket or a review.
The parse, the normalisation and the comparison all run in JavaScript on your own machine. There is no backend to send anything to — the whole site is a static export — so API responses holding customer records, config files holding connection strings, and fixtures from an unreleased service can all be compared without any of it crossing the network. That is a real difference from diff tools that upload both documents to a server before showing you the result.
Paste the original JSON into the left editor and the updated JSON into the right, then press Compare JSON. Both documents are parsed and rewritten into the same canonical form, so only real differences in the data are highlighted — removed content in red on the left, added content in green on the right.
No. Every object key on both sides is sorted before the comparison, recursively, so two documents holding the same data compare as identical regardless of the order their keys were written in. JSON objects are unordered by definition, so a moved key is not a change to the data.
Yes, and deliberately so. JSON arrays are ordered, which makes a moved element a genuine change to the data — a reordered list of pipeline stages or route rules behaves differently. Sorting arrays would hide exactly the changes most likely to break something.
Yes. Both sides are reparsed and re-emitted with the same two-space indentation, so a single-line payload from an API compares directly against the pretty-printed copy in your repository with no manual reformatting first.
The tool names which side failed and where, as a line and column with the reason, then compares both documents as plain text so you can still see what differs. The position is derived from the JSON grammar rather than the browser error message, because the most common mistakes are reported by most engines with no position at all.
Yes. The summary above the comparison lists every difference at its own path, such as $.scripts.test or $.items[2].id, grouped into missing properties, type mismatches and changed values. The counts act as filters so you can hide the kinds you are not interested in.
No. The parsing, normalisation and comparison all run in your browser. Easy Formatter is a static site with no backend, so neither document is transmitted anywhere and nothing is stored.
Yes, and it is one of the most common uses. Paste the response from before a deploy and the response from after, and the structural comparison strips out serialisation differences so you can see whether the payload actually changed shape or only changed formatting.
There is no imposed limit. Because the work happens in your browser rather than on a server, the practical ceiling is your own device memory rather than an upload cap or a rate limit.