Skip to content

Text Diff Checker

Line-by-line text comparison with the LCS algorithm — additions green, deletions red, unchanged lines plain. The same approach git diff uses.

In your browser—your files never leave your device.

Learn more
Diff level

About this tool

Paste two versions of any text (code, prose, config, CSV, a contract) and the tool shows you exactly what changed. Additions are highlighted in green, deletions in red, unchanged lines stay in default text. Line numbers run down both sides so you can reference specific lines in conversation. The underlying algorithm is LCS (Longest Common Subsequence), the same approach git diff uses: it finds the longest shared sequence between the two texts and treats everything else as add/remove. Comparison runs in your browser; nothing is uploaded. Useful when you don't have git handy and need to see what changed between two pasted versions of a document, a config block, or a chat-pasted code snippet.

How to text diff checker

  1. Paste the original on the left

    The "before" version. Any plain text: code, prose, config, CSV, a contract clause. Newlines preserved. Use the "Try a sample" button if you want to see the tool in action without your own text.

  2. Paste the modified on the right

    The "after" version. The two panes don't need to be the same length — the LCS algorithm aligns matching lines regardless. Pasting a longer modified than original is fine; the extra lines just show up as additions.

  3. Read the highlighted diff

    After a 300ms debounce, the diff renders below. Green rows are additions, red rows are deletions, plain rows are unchanged context. Line numbers run down both sides. Stats at the top show counts of added, removed, and unchanged lines.

  4. Copy the unified diff

    The "Copy Diff" button puts a standard unified-diff format (with + and - prefixes) on your clipboard. Paste it into a code review, a chat, an email, or save it as a .patch file for `git apply` later.

Why use this tool

You need a diff outside of git all the time and don't always notice. A friend sends you a "fixed" version of a contract — you need to see what they actually changed before signing. A coworker pastes a "tweaked" config snippet in Slack — you need to spot the typo that'll bring down the build. You're reviewing a translation against the original — you need to see which paragraphs the translator actually touched. CMS-pasted blog post versus the version in your editor — you need to know if the CMS quietly stripped formatting or rewrapped lines. Git's `git diff` is the right answer when you have both versions in a repo, but you usually don't have a repo for ad-hoc text. This is for the everyday case: two blobs of text, what changed, show me.

Features

LCS algorithm — same as git

Longest Common Subsequence is the standard algorithm for line-based text diffing. Git, Mercurial, and most diff tools use it because it produces minimal-change diffs that match human intuition about what was added vs deleted. The implementation here is the textbook DP version with backtracking, which means accurate diffs on any pair of texts — no heuristic that occasionally produces nonsense alignment.

Color-coded with line numbers

Green rows for additions, red rows for deletions, plain rows for unchanged context. Two columns of line numbers — original on the left, modified on the right — let you reference specific lines in conversation ("see line 47 of the original"). Modified-only lines have no original number; deleted lines have no modified number; matching lines show both.

Debounced live processing

The diff updates as you type or paste, with a 300ms debounce so the algorithm doesn't run on every keystroke. Pasting a large diff just shows the result; tweaking the text gives you a smooth update without the UI thrashing. The debounce keeps the tool responsive on long inputs where the LCS calculation isn't instant.

Unified-diff export

The "Copy Diff" button copies output in standard unified-diff format, same as `diff -u` or `git diff`. Useful for pasting into pull-request comments, code reviews, or saving as a .patch file you can apply with `git apply` or `patch`. The format is the de facto standard for sharing text diffs across tools.

Privacy & security

This tool runs entirely in your browser. Your files are never uploaded to a server — every step of the process (reading, transforming, downloading) happens on your device using JavaScript and the Web APIs. You can verify this in your browser's network tab: clicking the tool's main action triggers zero requests to our servers. The page itself is served over HTTPS, but once it loads, your data stays put. No accounts, no tracking of file contents, no scanning your inputs.

Frequently asked questions

What algorithm does it use?
Longest Common Subsequence (LCS) with the classic dynamic-programming implementation. Same approach git diff uses internally, though git layers a few heuristics on top for histogram and patience diffs, which produce slightly different alignments on certain pathological inputs. For normal text, LCS is the algorithm and the result is a minimal-edit diff that matches what humans would call "the actual change."
Does it work on code, or only prose?
Any plain text. Code in any language, prose, JSON, YAML, CSV, log files, contracts, transcripts, configuration files. The diff is line-based: anything with newlines compares cleanly. For binary files (images, PDFs, executables), a line diff is meaningless. Use a dedicated binary-diff tool or the binary diff that git produces when comparing tracked binary files.
How is this different from git diff?
Same core algorithm, different entry point. Git diff works on files that are in a repository — you need both versions tracked, staged, or committed. This tool works on two pasted blobs of text, no repo required. Use git diff when you have a repo; use this for everything else: Slack messages, CMS-pasted text, friend's emailed-back document, translation review, an "old" and "new" version from a knowledge-base export.
Line-level diff vs word-level diff?
This tool is line-level. Each row of the output is one line of text, fully added or fully removed if it changed. Word-level diffs (which highlight individual changed words within a line) are useful for prose review where you want to see exactly which words were edited. Line-level is the right default for code, where moving even one character on a line usually constitutes a real change. The unified-diff format is line-level by convention, so the export matches what most tools expect.
Privacy?
All processing happens in your browser. The text you paste isn't uploaded, logged, or analyzed. The LCS calculation is a JavaScript function running on your machine — no network call when you paste, you can verify in dev tools. This is especially important when diffing contracts, internal documents, or proprietary code: nothing leaves your device.
Size limit?
No hard cap, but LCS is O(n*m) in time and space, where n and m are the line counts of the two inputs. Texts over about 10,000 lines start getting slow because the DP table grows quadratically. 10,000 lines times 10,000 lines is 100 million cells, which takes meaningful memory and CPU. For really big files (megabyte+ logs, full codebases), use git diff or a desktop diff tool like Meld, KDiff3, or Beyond Compare, all of which use smarter algorithms for large inputs.
Three-way merge or merge previews?
Not in this tool. It's strictly two-way. Three-way merge (common ancestor plus two divergent edits) is what git merge does internally and what tools like KDiff3, Beyond Compare, and the merge view in VS Code visualize. If you need three-way merge to resolve conflicts, use a desktop merge tool. The vast majority of "what changed?" questions are two-way and this answers those.
Copy the diff?
Yes. The "Copy Diff" button produces standard unified diff format with + and - prefixes. Paste into a pull-request comment, a chat, an email, or save as a .patch file you can apply with `git apply patch.diff` or `patch < patch.diff`. The unified format is the standard interchange format for text diffs, supported by every code review tool and most chat platforms that render text changes.
Free?
Yes. No length cap, no signup, no premium tier. The whole thing is about 200 lines of TypeScript running locally — there's no infrastructure to charge for and no upstream cost to pass on.
Why does the diff sometimes show a line as both added and removed instead of "changed"?
Because line-level diffs treat each line as atomic: a line either matches its pair in the other text or it doesn't. If you change one character on a line, that line shows up as one deletion and one addition, not as a single "modified" entry. This is the standard behavior of every line-based diff tool, including git diff. Word-level or character-level diff tools (like the GitHub web UI's "split" view with the "highlight changes" toggle) handle that case more gracefully but at the cost of being noisier on large changes.