Text and JSON diff checker
Paste two versions of something and see what changed. Line diff uses a real longest-common-subsequence match, so an inserted line shifts nothing else. JSON diff compares the two documents structurally and names every path that differs. Both run in this tab and neither text goes anywhere.
Paste text into both boxes to compare them.
Both texts stay in this tab. Nothing is uploaded, logged or stored — no cookie, no local storage, no history. Close the tab and both are gone.
What a line diff is actually computing
Comparing two texts line by line is not a matter of walking both at once and reporting the lines that differ. Do that and inserting a single line at the top of a file makes every subsequent line look changed, which is both wrong and useless. The correct question is which lines the two versions have in common, in order — the longest common subsequence. Everything in that subsequence is unchanged; everything left over on the original side was removed; everything left over on the changed side was added. Insert one line and you get one addition and nothing else, which is what you wanted to be told.
The implementation here builds the full dynamic-programming table, then walks it once from the top to produce a unified list of entries, each carrying its type, its text and its line number on whichever sides it exists. Ties in the walk fall to a deletion first, so a line that was edited reads as a removal immediately followed by an addition rather than the other way round, which is the convention every other diff tool follows. Line numbers come from the original text, before any of the comparison options were applied, so the numbers beside the output are the numbers in your editor.
The three options change the comparison key without changing the text that gets displayed. Ignoring leading and trailing whitespace makes an indentation change invisible while leaving internal spacing significant, which is useful when a formatter has reindented a file and you want to see what else it did. Ignoring case is for comparing identifiers and configuration values. Ignoring blank lines removes them from the comparison entirely rather than treating them as matching content, and the surviving lines keep their original numbers, so a gap in the numbering is a blank line that was skipped rather than a bug.
Why JSON needs a different kind of diff
Run two JSON documents through a line diff and you learn very little. Reformat one of them and every line differs. Reorder the keys in an object, which changes nothing about what the document means, and again every line differs. Meanwhile a genuine change buried eight levels down shows up as one modified line among forty, with no indication of which key it belonged to. A line diff compares text; JSON is not text, it is a structure that happens to have a text representation. If one side is not valid JSON, check it with the JSON and YAML validator first.
The JSON mode parses both sides and walks the two values together, producing a list of paths that differ. Each entry names the path in the notation you would use to reach it in code — user.roles[2].name — along with what kind of difference it is and both values. Keys with awkward characters in them are bracketed and quoted rather than dotted, so a path stays something you could paste into a console. Additions and removals are keys present on one side only. Changes are keys present on both with different values of the same type. Type changes are called out separately, because a number that has become the string of that number is a specific and very common bug, and lumping it in with an ordinary value change hides it.
null is treated as a value in its own right, not as an absent key: a key whose value went from null to 0 is a type change, and a key that disappeared entirely is a removal. Arrays are compared by index, which is the honest simple choice and has one consequence worth knowing: inserting an element at the front of an array reports every later index as changed, because every later index genuinely does now hold a different value. Matching array elements by identity would need a key to match on, and JSON does not supply one.
Questions people ask
Is anything I paste sent to a server?
No. The comparison is plain JavaScript running on the two strings in the boxes, and nothing on this page makes a network request of any kind. Neither text is stored in a cookie, in local storage, or in the page history. Check it rather than believing it: open developer tools, go to the Network panel, clear it, paste both sides and watch. Nothing goes out. That matters more here than on most tools, because the two things people most often want to diff are configuration files and source code, and both tend to have credentials in them.
Why does my JSON diff say nothing changed when the files clearly differ?
Because they differ as text and not as data. Indentation, line endings, the order of keys within an object and the exact spelling of a number — 1.0 against 1 — are all invisible once the documents have been parsed, since none of them affects what the document means. That is the point of the mode. If what you actually need to see is the textual difference, whitespace and all, switch to line diff. The two modes answer genuinely different questions and it is worth being clear which one you are asking.
Why does inserting one array element mark everything after it as changed?
Because arrays are compared by index, and after an insertion at position zero every later index really does hold a different value than it did. A tool that reported this as a single insertion would have to work out which elements correspond, and for arrays of objects that means guessing at an identity field — an id, perhaps, or a name — which is a guess that goes wrong quietly. Comparing by index is predictable and never lies about what is at a given path. If you are diffing an array of records and the ordering is not meaningful, sorting both sides by the same key before pasting them gives a far more readable result.
How many lines can this compare?
Three thousand a side. The line diff builds a table with one cell for every pair of lines, so cost grows with the product of the two lengths: three thousand against three thousand is nine million cells, which stays comfortably under a tenth of a second. Ten thousand a side would be a hundred million, and the tab would stop responding. Rather than let that happen the page refuses the comparison and says so. For anything larger, git diff and diff -u use Myers' algorithm, which only pays for the differences it finds rather than for the whole matrix, and they handle files of any size on a laptop.
Can I diff two YAML files here?
Line diff works on YAML as it works on any text, and for a small edit that is often all you need. For a structural comparison, convert both documents with the YAML to JSON converter first and paste the results into JSON mode. That is not merely a workaround: YAML has anchors, aliases, several ways of writing the same scalar and a distinction between the null spellings, so a structural comparison of the parsed values is a more truthful answer than a comparison of the YAML text ever could be.