Free Diff Checker Online

Comparing 2 versions of a file by eye is slow and unreliable past a dozen lines. A diff tool automates it by computing the smallest set of insertions and deletions that turns the first text into the second, then showing those edits in place. The mental model that matters is the edit script: an ordered list of 3 operation types, keep this line, delete this line, add this line, that replayed against the original reproduces the modified version exactly. Everything a diff viewer shows, the green additions marked with a leading +, the red deletions marked with a leading -, the unchanged context with a blank marker, is just that script rendered with color. Editing 1 word in a 200-line file yields an edit script of length 2, 1 delete and 1 add, not 200. This tool works at line granularity, the same unit Git and code review tools use, because for source code and config files a line is the natural atom of change. The idea is old: the Unix diff utility shipped in 1974 with the 5th Edition of Unix, written by Douglas McIlroy and James Hunt, and its line-oriented output became the basis of the patch format still used 50 years later.

The engine underneath is the Longest Common Subsequence. The LCS of 2 sequences is the longest run of elements appearing in the same order in both, though not necessarily adjacent. Find the LCS and the answer falls out: every line in the LCS is unchanged, every line in the original but not the LCS was deleted, and every line in the modified version but not the LCS was added. The classic way to compute it is dynamic programming, filling an m by n grid where m and n are the line counts of the 2 inputs, each cell holding the LCS length of the prefixes up to that point. The recurrence is 1 rule: if the 2 lines match, the cell is 1 plus the diagonal neighbor, otherwise it is the larger of the neighbor above and the neighbor to the left. That grid costs O(m by n) in both time and memory, which is why this tool caps each side at 4000 lines: a 4000 by 4000 grid is 16 million cells, roughly 128 MB at 8 bytes per number, and past that a browser tab starts to stutter. A refinement due to Hirschberg in 1975 computes the same LCS in O(m by n) time but only O(m plus n) memory by recursing on the midpoint, the trick that lets command-line diff handle files of 100000 lines or more without exhausting RAM.

Everything runs in your browser: the 2 texts are split on newlines, compared, and rendered locally, so no source code, config, or document is uploaded or stored. 2 toggles change what counts as a match without changing what is shown. Ignore whitespace collapses runs of spaces and tabs and trims each line before comparing, so a reindented block reads as unchanged rather than as a wholesale rewrite, useful when a formatter has touched a file. Ignore case folds letters to lowercase for the comparison, so 2 lines differing only as Error and error count as 1 unchanged line. Both affect matching only; the original text is always displayed verbatim. The comparison is line-level, so a 1-character change inside a long line marks the whole line as removed and re-added rather than highlighting the single character, which is the right trade for code but coarser than a word-level or character-level diff would be for prose. The tool does not do 3-way merges, does not resolve conflicts, and does not understand syntax: it compares text as text, so a change that is semantically trivial to a compiler, reordering 2 independent functions, still shows as 1 delete plus 1 add.