Two files, same data, completely different text
JSON is unusually good at producing comparisons that look alarming and mean nothing. The format allows the same data to be written many ways: keys in any order, any amount of whitespace between tokens, objects on one line or spread over twenty. A configuration file that was regenerated by a different tool can be byte-for-byte unrecognisable while describing precisely the same thing.
So the first question to settle is which kind of difference you are actually chasing — a difference in the text, or a difference in the data. They are not the same question, and a comparison tool answers the first one.
What this tool does, and what it does not
This is a text comparison with syntax awareness. JSON is one of the parsed languages, which means the document is broken into structural blocks — an object, an array, a nested member — rather than into lines, so a relocated block is recognised as relocated rather than reported as a deletion and an unrelated addition.
What it does not do is parse both sides into values and tell you whether those values are equal. It has no notion that 1.0 and 1 are the same number, that "\u0041" and "A" are the same string, or that two objects with the same members in a different order are equivalent to a parser. It can show you clearly that the order differs; the judgement that this makes no difference to whatever consumes the file is yours.
That distinction is worth holding onto, because the output is often close enough to a semantic answer to be mistaken for one. If you genuinely need equivalence rather than difference, compare the parsed values in whatever language you are working in, or canonicalise both files first as described below.
Reordered keys
Object member order is not significant in JSON — the specification says an object is an unordered collection — and most consumers do not care. But it is significant in the text, so a comparison has to say something about it.
In Smart mode a reordered member is reported as a move, with a connector linking where it was to where it is now, and it costs almost nothing against the similarity score. That is usually the reading you want: a file whose keys were shuffled by a serialiser scores near-identical, because as far as the data is concerned nothing happened.
In Strict mode the same file reports the member as deleted from one place and added in another, and the score drops accordingly. Switch to Strict deliberately when order is meaningful to you — when the file is meant to be human-readable in a documented sequence, or when you are checking that a generator produced stable output rather than reshuffling on every run.
Reformatting, indentation, and minified files
There is no option here to ignore whitespace, so a file that was reindented from two spaces to four, or expanded from one line to many, differs from its original in this comparison. Depending on how far the formatting moved, blocks are usually still matched to each other and reported as modified with a high per-block score, rather than as wholesale replacements — but they are reported.
The reliable way to handle it is to canonicalise both sides before comparing, rather than hoping the comparison will look past it. Run both through the same formatter — jq ., python -m json.tool, or your editor's JSON formatter — and paste the results. Anything still marked as different afterwards is a difference in the document rather than in its presentation.
For minified JSON this is not optional. A minified file is often one enormous line, and beyond a few thousand characters a single line does not get word-level highlighting, so you would get a row correctly marked as changed with no indication of where. Format both sides first and the comparison becomes readable.
Arrays, where order usually does matter
Array order is significant in JSON, and this is the case where a reordering reported as a cheap move can mislead you. A list of middleware, a sequence of migrations, an ordered set of rules, a route table — reordering any of these changes behaviour, even though the comparison correctly observes that no element was added or removed.
When comparing arrays where sequence carries meaning, read the moves rather than the score, or use Strict mode so a reordering shows up as the substantial change it is. A near-100% Smart score on a reordered array is telling you the truth about content and nothing at all about behaviour.
Getting a useful result quickly
Format both sides with the same tool (jq . or your IDE's formatter), paste them in, and read the Smart result first — it highlights the genuine additions, deletions, and moved values across your data structures. Then glance at the Strict score: if the two numbers are far apart, the file was reorganised as well as edited, and it is worth knowing that before you conclude the change was small.
Comparing API payloads and sensitive configs privately
Developers routinely need to compare JSON API responses, database records, webhook payloads, and configuration files containing customer records, access tokens, or proprietary structures.
Because this tool executes all tree-sitter AST parsing and token diffing in a local browser Web Worker, no payload data is ever transmitted to a cloud server or logged in an external pipeline. You can safely diff production configurations and sensitive responses without violating data isolation policies. For the full architectural details, see our guide on client-side private comparison.
For files that are not quite JSON — environment files, INI, YAML, TOML, CSV — the failure modes are different enough to be worth their own page: see comparing CSV and configuration files.