Comparing two versions of a document is daily work far beyond code review — contract redlines, translation QA, configuration drift. Scanning by eye reliably misses a changed digit or a single extra space.
This checker compares two texts by character, word or line and colours additions green and deletions red. Switch between side-by-side and unified views, and ignore whitespace or letter case when those differences are noise. The result can be downloaded as a standard unified diff (.patch) to attach to a review.
How to use
- Paste both versions — Original on the left, changed version on the right. If you pasted them the wrong way round, the swap button fixes it.
- Choose the granularity — Line for code and configuration, word for prose and translation review, character for short strings and numeric comparison. Results recalculate immediately.
- Filter out noise — Turn on ignore whitespace when only indentation moved, and ignore case when only capitalisation changed, so what remains is real content change.
- Save the result — Check the added/removed/unchanged counts at the bottom and download a patch file if you need one — the unified format applies with
git applyand attaches cleanly to review systems.
Frequently asked questions
Is my pasted code sent anywhere?
No. The diff algorithm runs in your browser and makes no network requests.
This tool is often used on internal source and draft contracts, so it was built without a server from the start. Open your browser's network tab while comparing to confirm.
Line or word granularity — which should I use?
It depends on what changed.
Code defaults to lines. Renaming one variable marks the whole line as removed and added, but that matches how git and every code review tool present changes, so it reads naturally. Prose is different: reflowed line breaks make line diffs mark whole paragraphs as changed and tell you nothing. Word granularity pinpoints the actual edits.
It slows down on large files.
Diff cost grows close to quadratically with input size, and character-level comparison degrades fastest.
For files of several thousand lines, switch to line granularity first, and if it is still slow, paste only the region you care about. For a recurring comparison over whole files, git diff or diff -u on the command line is far more efficient.
Concepts worth knowing
How diff algorithms work
Most diff tools find the longest common subsequence of the two inputs: maximise what is shared and whatever remains is naturally a deletion or an insertion.
The widely used Myers algorithm reframes that as a shortest-path problem on a graph, which makes it fast enough in practice. The shortest edit script is not always the most readable one, which is why git also offers --histogram and --patience, variants that optimise for human legibility instead.
Reading a unified diff
In a .patch file, @@ -12,7 +12,9 @@ is a hunk header meaning seven lines starting at line 12 of the original become nine lines starting at line 12 of the new version. In the body, - marks removals, + marks additions, and a leading space marks unchanged context.
Three lines of context are included by default so the patch can be located even if the surrounding file has shifted slightly.
Whitespace noise
Mixed tabs and spaces, or an editor stripping trailing whitespace, can mark an entire file as changed while the logic is untouched. It is the classic reason reviewers cannot find the real change.
Prevent it with an .editorconfig plus a formatter (Prettier, Black) enforced in CI. Line-ending differences between Windows and Unix (CRLF versus LF) cause the same problem and are handled with git's core.autocrlf or a .gitattributes file.