Compare JSON Files Online

JSON is the dominant format for API responses, configuration files, feature flags, and data exports. When JSON objects are serialised differently, one minified and one pretty-printed, or one with keys in alphabetical order and another preserving insertion order, a naive text diff flags almost every line as changed even when the actual data values are identical. This key-order and whitespace sensitivity is the biggest obstacle to useful JSON comparison. The solution is to normalise both files to identical formatting before diffing: same indentation depth, same key ordering, same quoting style. Once normalised, the diff output reflects only genuine changes in data values, key names, or structure rather than serialisation differences.

FixTools handles JSON comparison most effectively through a two-step process. First, use the JSON Formatter to parse and re-serialise both JSON documents with consistent indentation (typically two or four spaces) and optionally sorted keys. This step removes all whitespace noise and resolves key-ordering differences between the two files. Second, paste both formatted outputs into the Diff Checker panels and run the comparison. The Myers algorithm then operates on semantically normalised text, so every highlighted difference represents a real change in data value, key name, or structural organisation. Nested objects and arrays are compared recursively at the line level, making even deeply nested differences clearly visible in the output.

After you have the diff, pay close attention to value changes inside unchanged-looking keys: these are the most common source of subtle bugs in API integrations and configuration drift. A field name that appears identical can have a changed value type, a changed unit, or a changed default that only becomes visible when you look at the highlighted value on the adjacent line. Use the side-by-side view to compare corresponding nested blocks from each document and confirm that the structural hierarchy is consistent between both versions.

JSON is unambiguous about character encoding: the specification requires UTF-8, UTF-16, or UTF-32, and most production JSON in transit is UTF-8 by default. That means encoding mismatches are rarely the source of false diff positives in practice, unlike with raw text files where CRLF versus LF endings dominate the trouble reports. The line-based Myers diff handles JSON well after formatting because pretty-printed JSON places each key-value pair on its own line, giving the algorithm clean atomic units to align. Performance is excellent up to JSON documents in the low megabytes range; beyond that, splitting the input by top-level array element or by major object section produces both faster diffs and more readable output. Because the comparison runs entirely client-side, JSON payloads containing API keys, customer records, or session tokens are safe to paste, since no part of the document is transmitted off the device or written to durable storage.

It is worth distinguishing semantic JSON diff from textual JSON diff because the two approaches answer different questions. A textual diff like the one FixTools produces operates on the formatted text of the two JSON documents and reports any line-level difference, which means it is sensitive to key order, array order, and number formatting choices like trailing zeros or scientific notation. A semantic JSON diff, by contrast, parses both documents into in-memory trees and compares them structurally, treating key reordering as a non-change and matching array elements by content rather than position. Each model has a place. For verifying that two API responses are byte-identical after deserialisation and reserialisation, the textual approach with the FixTools JSON Formatter applied to both inputs is faster and produces a more readable, line-anchored output that you can save as a PDF. For comparing semantically equivalent documents that differ only in serialisation order, a textual diff requires a pre-processing step. The most effective pre-processing tool is jq, the command-line JSON processor, which can canonicalise documents with jq --sort-keys on both files before pasting. Schema-aware comparison goes further by ignoring fields the schema marks as ephemeral, such as timestamps or nonce values, and is the right model for contract testing against an OpenAPI or JSON Schema definition. For that workflow, generate the canonical form with a schema-aware tool first, then paste the canonical outputs into FixTools for the final readable visual diff that you can share with a non-technical reviewer.