Text Diff Checker: Compare Two Texts

How to use the diff checker

1. Paste the original version into the left Original Text box (or click Load Example to try a sample).
2. Paste the new version into the right Modified Text box.
3. Pick a View Mode: Side by Side for two columns, or Inline for a single unified stream.
4. Press Compare. Removed lines turn red, added lines turn green, unchanged lines stay neutral.
5. Read the stats bar for the count of + added, - removed, and unchanged lines.
6. Click Copy or Download to export the result as a unified .txt diff.
7. Use Swap to flip which side is original, or Clear to start over.

How the diff algorithm works

Toolk splits both inputs into lines, then computes their Longest Common Subsequence (LCS) with a classic dynamic-programming table. The LCS is the longest ordered set of lines the two versions share. Anything in the original but not in that subsequence is marked removed; anything in the modified version but not in it is marked added. This is the same line-matching idea Eugene Myers formalized in his 1986 paper "An O(ND) Difference Algorithm and Its Variations", which unified the shortest-edit-script and LCS problems that drive git diff.

The export follows the unified diff convention standardized in POSIX.1-2008 (The Open Group diff utility): a --- line for the original, a +++ line for the modified file, then each line prefixed by + (added), - (removed), or a space (context).

Worked examples

The built-in example compares a JavaScript function before and after a refactor. Here is roughly what the inline (unified) output looks like:

--- original
+++ modified
- function greet(name) {
-   console.log("Hello, " + name);
-   return true;
+ function greet(name, greeting = "Hello") {
+   console.log(greeting + ", " + name + "!");
+   return { success: true };
  }

  const user = "World";
- greet(user);
+ const result = greet(user, "Hi");

Config drift example. Compare two .env files and only the changed keys light up. Input A has PORT=3000; input B has PORT=8080. Because each whole line is matched, the diff reports the old line removed and the new line added, even though only four characters changed.

Failing edge case — trailing whitespace. The line name: api (with one trailing space) does not match name: api. The live comparison is exact, so a stray space or a tab-vs-spaces change shows the entire line as removed and re-added. If that is noise, strip whitespace first with Find and Replace.

The memory limit most diff tools never mention

Toolk's comparison fills a full (m + 1) × (n + 1) dynamic-programming table, where m and n are the line counts of the two sides. That means both time and memory grow as O(m × n), not the near-linear O(ND) of git's optimized Myers implementation. The practical effect: two 50-line inputs build a ~2,600-cell table and finish instantly, but two 20,000-line files would allocate a ~400-million-cell table and can stall the browser tab. For very large files, diff in smaller sections or use a command-line tool. Most web diff checkers hide this; we state it so you know the real ceiling.

One more honest note: the export writes +/-/space line prefixes and ---/+++ headers, but it does not emit @@ -l,s +l,s @@ hunk headers. It is a readable change log, not a patch you can feed straight into git apply.

What people compare with it