Semantic JSON diff · Duplicate-aware paths · Runs locally
Paste two JSON documents into the diff checker to find added, removed, and changed values. Compare parsed data by path, keep arrays positional or treat them as unordered, and require exact number tokens when spelling matters.
Loading the JSON diff checker…
Enable JavaScript to compare two JSON documents in your browser.
Three clear steps
Use the online JSON compare tool for API responses, configuration files, test fixtures, webhook payloads, or any other pair of strict JSON documents. It performs a data comparison; if the source serialization itself is the deliverable, read the semantic-versus-text distinction below.
Put the expected or earlier document on the left and the actual or newer document on the right. Remove credentials, access tokens, and personal data before working with any diagnostic example.
Keep arrays positional for standard JSON behavior, or select unordered comparison for set-like data. Turn on exact number tokens when 1, 1.0, and 1e0 must remain different.
Check additions, removals, type changes, and modified values in context. Confirm the array-order rule and inspect any duplicate-key warning before treating the documents as equivalent.
Choose the right definition of “different”
Two files can contain the same JSON data while looking very different, and two similar-looking files can represent different data. The correct comparison depends on the question you are trying to answer.
A semantic JSON diff parses both inputs before comparing them. Whitespace outside strings does not become a change, and object member placement can be ignored because a JSON object is defined as an unordered collection. This is the comparison LiveParse performs, and it is usually the useful view for API regression checks, configuration reviews, and tests that care about values rather than formatting.
A text diff compares the source representation. Reindentation, line-ending changes, escaped characters, property movement, and number spellings such as 1, 1.0, and 1e0 can remain visible. Use this view when reviewing a generated artifact, a version-controlled file, a signature-sensitive payload, or an exact serialization contract.
Neither approach is universally better. Semantic comparison deliberately removes some source-level detail; text comparison deliberately reports changes that may not alter the parsed value. LiveParse keeps exact number spelling available as a semantic comparison option, but it does not present a raw line-by-line text diff. Use a version-control or text-diff tool as a complementary check when the entire serialization is the artifact under review.
Order changes the answer
JSON objects and arrays have different ordering semantics. Treating them with one blanket rule creates noisy results or, worse, hides a real change.
RFC 8259 describes an object as an unordered collection of name/value pairs. Moving "name" above "id" normally changes the source text but not the object’s meaning. A semantic comparison should match members by name, not by line position.
An array is an ordered sequence. Swapping the first and second items changes their indices even when the same values remain present. Ordered comparison is the standards-aligned default for queues, ranked results, coordinate pairs, and step sequences.
Some APIs use arrays to carry set-like tags, permissions, or feature names. Ignoring order can reduce noise for those fields, but JSON itself does not declare an array to be a set. Confirm whether duplicates and repeated objects are significant before using an unordered rule, then follow the guide to comparing JSON while ignoring array order.
A list of records may be matched by position, or an application may choose a stable key such as id. A generic JSON diff cannot safely invent that identity rule. If order is unstable, verify records and repeated IDs before accepting the comparison.
Preserve the evidence in the source
Numbers and repeated member names expose differences that ordinary JSON.parse()-based comparison can erase. They deserve an explicit review when data integrity matters.
JSON defines a number grammar, but it does not require every implementation to preserve arbitrary precision or the original token spelling. Large integer identifiers may exceed JavaScript’s exact integer range, and long decimals may be rounded when converted to a binary floating-point value. Even when they represent the same mathematical quantity, 1, 1.0, and 1e0 are different source tokens.
An exact-token comparison is useful for 64-bit IDs, monetary decimals, scientific measurements, negative zero, and serialization tests. A value-oriented comparison may intentionally consider numerically equivalent forms equal; a source-oriented comparison should keep the distinction visible. Choose the rule that matches the downstream consumer.
Object names should be unique for interoperable JSON, yet the grammar does not make repeated names a syntax error. Many parsers keep only the last value, so {"role":"user","role":"admin"} can lose evidence during ordinary parsing. Inspect every duplicate-key warning and repair the producer rather than guessing which occurrence was intended.
Practical comparison workflows
A useful comparison starts with a focused question: which contract, record, or environment changed? Keep the smallest representative payload that still demonstrates the behavior.
Place a fixture or snapshot on the left and the failing response on the right. A semantic diff can reveal a missing property, a string-to-number type change, a changed nested value, or an array item that moved. Use the API response comparison workflow to redact volatile fields and verify contract changes.
Compare representative responses from two versions or deployments. Pay attention to renamed fields, new nullable values, pagination metadata, error shapes, and order-sensitive collections that clients may depend on.
Normalize environment-specific IDs, timestamps, and URLs in a safe copy, then compare the remaining structure. Do not paste secrets or live customer records; use redacted or synthetic examples whenever possible.
Compare a working event with a rejected one to isolate schema drift, absent fields, changed enum values, or a different item sequence. Preserve exact numbers when event IDs and monetary values must not be rounded.
Use this semantic checker to ignore harmless reformatting, then add a separate version-control or text diff when stable serialization is part of a code review. A moved object member and a moved array item should not be interpreted as the same kind of change.
Confirm the source JSON first, then use the JSON to CSV converter when the records need a spreadsheet-ready table. For one-record-per-line data, use the JSONL parser.
When a diff contains opaque epoch values, open the Unix timestamp converter to identify seconds, milliseconds, microseconds, or nanoseconds and inspect the corresponding UTC date without rounding the original integer.
Questions answered
A JSON diff describes differences between two JSON documents. A semantic diff reports changes to parsed values and paths, while a text diff reports changes to the written source. The results can differ because whitespace and object member placement do not necessarily change the data.
Not to the JSON data model: an object is an unordered collection of name/value pairs. Object order may still matter to a source-text review, a human-readable convention, or a nonstandard downstream system, so use text diff when placement itself is under review.
Yes. JSON arrays are ordered, and an item’s index is part of its position in the document. Treat an array as unordered only when your application explicitly defines it as a set-like collection and you understand how repeated values should be handled.
The tokens 1, 1.0, and 1e0 can represent the same mathematical value but have different source spellings. Large integers and long decimals can also be rounded by parsers. Use exact token comparison when spelling or precision is part of the contract.
Behavior varies by implementation: a parser may keep the first value, keep the last value, preserve every occurrence, or reject the document. RFC 8259 says object member names should be unique for interoperability. Treat a duplicate-key finding as an ambiguity to fix, not as a harmless formatting detail.
No. A diff is a description of observed differences. JSON Patch, standardized in RFC 6902, is a specific array of operations such as add, remove, and replace that a compatible system can apply to a document. Not every visual diff is a safe or complete patch.
A semantic comparison requires both sides to parse as JSON. Text comparison can still show source differences, but it cannot establish JSON-level equivalence. If an input has comments, trailing commas, single quotes, or truncation, inspect it with JSON Repair before comparing the repaired result.
The interactive comparison runs in the current browser tab. Your pasted documents are not required to be sent to a comparison API. You should still remove passwords, tokens, private keys, and personal data before placing any sensitive diagnostic payload in a browser tool.