JSON diff

Paste two JSON documents, such as two API responses or two versions of a config. Both are parsed, their keys sorted and re-indented before the comparison, so a different key order or formatting is not reported as a change: only added, removed and changed values are.

Original text
Open a file: Changed text
Open a file:

Or drop a file on either box.

View
Whitespace

Normalize JSON first: sort keys, indent 2 spaces

Only changes (fold unchanged lines) Highlight changed words Ignore case

What the JSON normalization does

With Normalize JSON first on, each side is parsed and printed again with its object keys in alphabetical order and a 2-space indent, then the two results are compared line by line. In the example, the second document lists its keys in a different order and on separate lines, yet only the four real changes show up: plan, rate_per_min, a new tag and the last digit of order_ref.

Arrays keep their order. In JSON, ["a","b"] and ["b","a"] are different values, so a reordered array is shown as a change.
Large numbers stay exact. Plain JSON.parse rounds integers above 2⁵³, so 90071992547409931 and 90071992547409932 both become 90071992547409940, and a diff built on it reports them as equal. This page keeps the original digits of any number that would be rounded, in browsers with JSON source text access (recent Chrome, Edge and Firefox); if yours lacks it, the summary says which numbers were affected. Numbers with the same value in another notation, like 1.0 and 1, count as equal.
Invalid JSON is compared as plain text, and the summary shows the parser's error so you can find the broken spot.
Line numbers and the downloaded .diff refer to the normalized JSON. Turn the option off to compare the raw texts.

How the comparison works

The texts are compared line by line with the Myers algorithm, the same one behind git diff and GNU diff, so the result is the shortest list of removed and added lines that turns the original into the changed text. Where a block of lines was replaced, each removed line is paired with the added line in the same position and compared word by word, so a one-word edit in a long paragraph is marked on that word instead of the whole line. When two lines have less than half their text in common, they are shown as a plain removal and addition.

We checked it against GNU diffutils on 400 random pairs of files, including files that do not end with a line break: the number of changed lines matched diff --minimal every time. Very different files stay fast because lines that appear on only one side are set aside before the search (GNU diff does the same). Two 20,000-line files with nothing in common compare in under 0.1 s. When two long files share many lines in a scrambled order, the search is cut short to stay fast, and the page tells you when that happened.

A .diff that patch and git apply accept

Download .diff saves a unified diff (the diff -u format, with 3 lines of context and \ No newline at end of file markers where needed). In the same 400-pair test, every downloaded patch applied cleanly with both patch -p1 and git apply and reproduced the changed file byte for byte. The file names in the header come from the files you opened, so you can send the patch to someone who has the original file:

patch -p1 < original.diff
git apply original.diff

If you compare with an ignore option on, lines that only differ in whitespace or case count as unchanged, so the patch keeps the original's version of them, exactly like diff -w.

Whitespace, case and line endings

Ignore at end skips trailing spaces and tabs, the usual noise from editors (like diff --ignore-trailing-space).
Ignore amount treats any run of spaces as one space and ignores indentation changes at the start and end (like diff -b, plus leading space). Good for re-indented code and re-wrapped prose.
Ignore all removes every space before comparing (like diff -w).
Line endings (Windows CRLF vs Unix LF) are never counted as changes; if the two texts use different ones, the summary says so. A missing line break at the very end is reported too.

Compare web pages, PDFs and images too

For two PDF versions, Compare PDFs extracts the text and shows the changed words with page numbers. For screenshots, Compare images highlights the pixels that changed. To track what changed on a live web page, the Shotmint API returns its readable text as Markdown (POST https://shotmint.creasework.com/v1/content) or a screenshot (/v1/screenshot), 1 credit each with 25 free renders a month. Scripts and AI agents can get a key with a bare POST https://shotmint.creasework.com/v1/keys/free (no body, JSON reply), then diff today's text against yesterday's.

Get 25 free renders a month API docs

FAQ

Are my texts uploaded? No. The comparison runs in your browser and this page sends nothing to a server, so it is safe for contracts, code and configs with secrets.

How large can the files be? Tens of thousands of lines work well: a 30,000-line file with 5% of its lines edited compares in about 0.1 s. The table shows at most 20,000 rows; turn on Only changes for longer results, or download the .diff.