Text diff checker
Paste two versions of any text and see exactly what changed — line by line, word by word.
The history of diff
Comparing two versions of a text automatically is a 1970s invention. The original diff program was written by Douglas McIlroy at Bell Labs in 1974 for Unix, built on what became the Hunt–McIlroy algorithm for finding the longest common subsequence between two files. The idea proved foundational: every version control system since — from RCS through Subversion to Git — is essentially machinery built around diffs, storing and displaying changes rather than whole copies. The green-for-added, red-for-removed convention that this tool uses comes straight from that lineage and is now the universal visual language of change tracking, from GitHub pull requests to Wikipedia edit histories.
Line-level and word-level differences
The diff checker compares text at two levels of detail. At the line level it identifies which lines were added, removed, or modified. When a line is modified rather than completely replaced, the tool also runs a word-level comparison on that specific line pair, highlighting exactly which words changed inside it. This makes it easy to spot a single word correction in a long paragraph without reading the whole line twice.
Who uses a text diff checker
Writers use the diff checker to compare draft versions of an essay or article and see what they or an editor changed. Developers use it to compare config files, documentation, or any text that is not in version control. Students use it to compare their submission against a revised or corrected version. Translators use it to track changes in the source document between review cycles. Anyone who has two versions of a text and wants to know exactly what is different will find it useful.
Frequently asked questions
How does the text diff checker work?
Paste the original text in the left panel and the revised version in the right, and the comparison runs automatically — no button needed. Under the hood, a longest-common-subsequence algorithm computes the minimum set of insertions and deletions that turns one text into the other, the same approach the classic Unix diff tool pioneered. That minimality matters: instead of flagging everything after the first change, the result pinpoints only the lines and words that actually differ.
What do the colours in the diff result mean?
Green lines with a + prefix exist only in the modified version — they were added. Red lines with a - prefix exist only in the original — they were removed. Unprefixed lines are unchanged. When a line was edited rather than replaced, the old and new versions appear as a red/green pair with the specific changed words highlighted in a stronger shade inside each line, so you can spot a one-word correction in a long paragraph without re-reading the whole thing.
Can I compare documents, essays or config files?
Yes — anything that is plain text: essays, emails, contracts, source code, config files, JSON, CSV or Markdown, up to 3,000 lines per side. Formatted documents like Word files should be pasted as text; the formatting is dropped but the words compare cleanly. Line-based comparison works best when the text has natural line breaks, so for one long paragraph the word-level highlighting inside the modified line does the heavy lifting.
Can I use the diff checker to detect plagiarism?
A diff checker is not a plagiarism detector, but it is ideal for closely comparing two versions of the same document — a submitted essay against an earlier draft, a contract against the previous revision, or an edited article against the original. It highlights every insertion, deletion and change line by line, which is often more precise than a similarity score when you need to see exactly what was modified.
How do I copy or save the diff result?
Click Copy diff above the result panel to copy the comparison in unified diff format — each added line prefixed with + and each removed line with -. This is the same plain-text convention used by Git and code review tools, so the output pastes cleanly into an email, a document, an issue tracker or a code review comment, and anyone technical will read it without explanation. For a permanent record, paste it into a text file and save it alongside the documents you compared.