Compare Two JSON Documents Structurally
Comparing two JSON documents by eye is painful and unreliable. A plain text diff makes it worse, because it flags every reordered key and every whitespace change as a difference even when the data is identical. What you actually want to know is whether the meaning of the two documents differs: did a field appear, did one vanish, did a value change, or did a value keep its content but switch type. This checker answers exactly those questions. It parses both sides into objects and walks them recursively, comparing by structure rather than by characters, so the result reflects real changes in the data instead of cosmetic noise.
The comparison is deliberately structural and order-insensitive. When the tool encounters two objects, it matches their keys by name, not by position, which is why an object with keys a then b is considered equal to the same object written with b then a. For every key it then decides which of four categories applies. A key present only in the second document is reported as added. A key present only in the first is reported as removed. A key present in both is compared by value, and if the values are equal nothing is reported, while if they differ the tool checks their types. When the type is the same but the content differs, it is a value change. When the type itself differs, such as a number becoming a string, it is reported as a type change, which is a distinct and often more serious signal because it usually points to a schema or serialisation problem rather than an ordinary edit.
Two small examples make the rules concrete. Compare the object with a set to one and b set to two against the object with b set to two and a set to one. Because keys are matched by name and both documents carry the same keys with the same values, the tool reports no changes at all, even though the keys were written in a different order. Now compare the object where a is the number one against the object where a is the string one. The keys line up, but the first value is a number and the second is a string, so the tool reports a type change on a from number to string. That distinction matters because the two look almost identical when printed, yet code that expects a number would break on the string, and only a structural comparison surfaces the problem clearly.
These behaviours map onto real work. A backend developer compares an API response before and after a code change to confirm that a refactor did not accidentally alter the payload, catching an unintended field rename immediately. A tester stores a known-good response as a snapshot and diffs each new run against it, turning regression detection into a glance at the added and removed lists. An operations engineer compares two versions of a configuration file to see precisely which settings moved, without being distracted by reordered keys from a formatter. A data engineer validates that a transformation preserved every field by diffing the input against the output and confirming the only changes are the ones the transformation intended. In each case the value is that the report contains signal and not noise.
A few points help you read the results correctly. Treat a type change as a louder alarm than a value change, since a number turning into a string or an object turning into null usually indicates a bug in serialisation rather than a normal update. Remember that arrays compare by position, so inserting an element at the front can shift every later element and produce a long list of differences even though the set of values barely changed; when order does not matter to you, sort both arrays first. Keep in mind that formatting, indentation, and key order are invisible to this tool by design, which is exactly what separates it from a text diff. Everything runs in your browser, nothing is uploaded, and both documents stay entirely on your own device throughout the comparison.