Text Diff Checker

Comparing two versions of a document, a config file, or a block of code by eye is slow and unreliable once more than a few lines have changed — it is easy to miss a single altered line buried in an otherwise identical paragraph, or to misjudge whether a line moved versus was actually deleted and a different one added in its place. A proper diff algorithm answers this precisely: given two sequences of lines, what is the smallest, most sensible set of line removals and additions that turns the first into the second? This tool implements that from first principles using the Longest Common Subsequence (LCS) algorithm at the line level — the same underlying idea used by tools like the Unix `diff` command and `git diff`. The two texts are each split into an array of lines, and a dynamic-programming table is built where each cell `dp[i][j]` holds the length of the longest common subsequence between the remaining lines of the original text (from line `i` onward) and the remaining lines of the changed text (from line `j` onward). Filling that table takes work proportional to the product of the two line counts (`O(n × m)`), which is why very large inputs are capped — see below. Once the table is filled, a backtracking pass walks from the start of both texts to the end, and at each step: if the current lines in both texts match, it is recorded as "same" and both pointers advance; otherwise, the algorithm looks at which neighboring cell in the DP table has the larger value to decide whether the current original line was removed or the current changed line was added, and advances the corresponding pointer. The result is a single ordered list of same/added/removed operations that, when read top to bottom, explains exactly how to transform the original text into the changed text one line at a time. This is a line-level diff, not a character-level or word-level diff — a line that has even one character changed shows up as one full "removed" line (the old version) immediately followed by one full "added" line (the new version), rather than highlighting just the changed word or character within that line. Line-level diffing is the right granularity for the vast majority of real use cases (comparing paragraphs, config files, code, CSV rows, changelogs) because it matches how people actually think about "what changed" in structured or semi-structured text, and it is dramatically cheaper to compute than character-level diffing on anything beyond a few lines. If you need to see exactly which word changed within a line, visually comparing the removed/added line pair side by side (they appear immediately adjacent to each other in the output) is usually enough to spot the difference at a glance. Because the DP table's size grows with the product of both texts' line counts, comparing two very large documents (tens of thousands of lines each) would require a table with hundreds of millions of cells, which would freeze the browser tab for a noticeable amount of time — an unacceptable trade-off for a tool meant to feel instant. To keep the comparison responsive, input is capped at 2,000 lines per side; if either side exceeds that, a clear message explains the limit rather than the tab silently hanging. For the overwhelming majority of real comparisons (a paragraph, a function, a config file, a changelog), 2,000 lines is far more headroom than needed. The comparison recomputes automatically as you type in either box, with a short debounce delay (200ms) so it does not needlessly recompute the full DP table on every single keystroke while you are still typing or pasting — a small deliberate trade-off between "instant" and "not wasting CPU on intermediate keystrokes", not a requirement of the algorithm itself.