Text Diff Tool
Compare two versions of any text and see exactly what changed. Choose line, word, or character comparison, switch between side-by-side and unified views, and export a standard .diff file. Optionally ignore whitespace or case. Everything runs in your browser — nothing is uploaded. Free, no signup.
Paste text into both panes, then press Compare (or Ctrl/Cmd + Enter).
Word and character modes highlight the exact changes inside each altered line. Everything runs in your browser — nothing is uploaded.
How to Use This Tool
- Paste the original text on the left — drop in the earlier version, or press Sample to load a worked example.
- Paste the changed text on the right — add the newer version you want to compare it against.
- Choose a comparison level — line shows which rows changed; word and character highlight the exact edits inside each changed line.
- Review, then copy or export — switch between side-by-side and unified views, then copy the diff or download it as a .diff file.
About Text Comparison & Diff Algorithms
A diff answers one deceptively hard question: what changed between these two versions? Reading two documents side by side and spotting the differences by eye is slow and unreliable, and it gets worse as the text grows. A diff tool does it mechanically and exhaustively, marking every insertion and deletion so nothing slips past. That matters whenever accuracy has consequences — comparing a contract against its redlined version, checking what an editor changed in your draft, confirming which config values moved between environments, or verifying that a translated page still matches the source.
Nearly every diff tool, this one included, is built on the longest common subsequence problem. The idea is to find the longest sequence of lines that appears in both texts in the same order, though not necessarily next to each other. Whatever is left over on the left side is a deletion, and whatever is left over on the right is an insertion. Solving it exactly uses a dynamic-programming grid comparing every line of one text against every line of the other, which is thorough but grows with the product of the two lengths. This tool solves it exactly for normal documents and switches to a faster prefix/suffix method on very large inputs so the page stays responsive.
Choosing the right granularity changes what you actually see. Line-level is the default and the right choice for code, configuration, and structured data, where a line is a meaningful unit. Its weakness is that changing one word marks the whole line as replaced, which tells you where to look but not what moved. Word-level refinement fixes that for prose: it re-diffs inside each changed line so a single altered word is highlighted and the rest of the sentence stays calm. Character-level goes finer still, which is ideal for catching a changed digit in a price, a flipped letter in a URL, or a swapped punctuation mark, but it becomes noisy on ordinary sentences.
The two option toggles solve a common annoyance. Ignoring whitespace collapses runs of spaces and trims line ends before comparing, which hides pure reformatting — re-indentation, a reflowed paragraph, trailing spaces from a copy-paste — so only real content changes remain. Ignoring case does the same for capitalisation, which is useful when comparing text that has been through a style pass. Both affect only how lines are matched, never how they are displayed, so what you see on screen is always the genuine text. Turn them off when whitespace or case is the thing you are actually auditing, as it is in YAML, Python, or Markdown.
The unified format you can export here is the same one Git, patch, and code review tools use: a leading space for context lines, a minus for removals, a plus for additions. That makes the output portable — paste it into a ticket, attach it to a pull request, or hand it to a colleague and it reads the way they expect. Worth being clear about the boundary, though: a diff tells you what changed, not whether the change was correct or who made it. That history belongs in version control. If your team is managing content revisions by emailing documents back and forth, a diff tool treats the symptom; a real content workflow treats the cause.
Pair this with our Case Converter for consistent casing before you compare, Find and Replace for bulk edits, and the JSON Validator when you need to compare structured data rather than prose.
Frequently Asked Questions
What is the difference between line, word, and character diff?
They control how finely the comparison is broken up. Line-level treats each line as one unit, so any change anywhere in a line marks the whole line as replaced. That is ideal for code and configuration, where lines are meaningful. Word-level re-compares inside each changed line and highlights only the words that actually differ, which is much easier to read for prose. Character-level goes down to individual characters and is best for spotting a single changed digit, letter, or punctuation mark, though on normal sentences it produces a lot of visual noise. Start with line, then switch to word when you need to see what changed rather than just where.
What is the LCS algorithm and why is it used for diffs?
LCS stands for longest common subsequence. Given two texts, it finds the longest sequence of lines that appears in both, in the same order, though not necessarily consecutively. Everything in the first text that is not part of that shared sequence must be a deletion, and everything in the second that is not part of it must be an insertion. This produces the smallest, most readable set of changes rather than naively reporting that everything after the first difference was replaced. The trade-off is cost: solving it exactly compares every line of one text against every line of the other, so very large inputs need a faster approximation.
What is the unified diff format?
It is the standard text format that Git, the patch command, and most code review tools use. Each line carries a one-character prefix: a space means the line is unchanged context, a minus means it was removed from the original, and a plus means it was added in the modified version. Headers mark which file each side came from. The format is useful precisely because it is boring and universal: you can paste it into a ticket, attach it to a pull request, or email it to a colleague and it will read correctly everywhere. This tool exports exactly that format when you click Copy diff or Export.
What does the "ignore whitespace" option actually do?
It collapses runs of spaces and tabs into a single space and trims the start and end of each line before the lines are matched against each other. The effect is that pure formatting changes stop showing up as differences: re-indentation, a reflowed paragraph, or trailing spaces picked up from a copy-paste. It only affects matching, never display, so the text you see is always exactly what you pasted. Leave it off when whitespace is itself meaningful, which is the case in Python, YAML, Markdown, and anywhere indentation carries structure.
Should I diff code and prose the same way?
No, and the difference is mostly about granularity. For code, line-level with whitespace sensitivity on is usually right, because a line is a statement and indentation often matters. For prose, line-level alone is frustrating, since editors reflow paragraphs and a single reworded sentence can mark an entire block as changed. Word-level is far more readable there. Turning on ignore whitespace also helps with prose, because it hides differences created purely by line wrapping. As a rule: code wants precision about structure, prose wants precision about meaning.
Can this tool do a three-way merge?
No, and that is a deliberate scope choice. This is a two-way comparison: it shows the differences between exactly two texts. A three-way merge compares two changed versions against a shared common ancestor so it can tell an addition apart from a deletion the other side made, and it needs a way to record and resolve conflicts. That is genuinely the job of a version control system. If you regularly need three-way merges, use Git with a dedicated merge tool rather than a browser-based comparison, and keep this tool for quick two-way checks.
How is this different from a Git diff?
The algorithm is closely related, but the context is completely different. Git diffs files that are tracked in a repository, so it knows the full history: who changed each line, when, on which branch, and in which commit. It can also diff across many commits and detect renamed files. This tool compares two blocks of text you paste in, with no history and no repository. That is a limitation when you need provenance, and an advantage when the text is not in version control at all — a pasted email, a client document, a CMS field, or two config values from different servers.
Is my text uploaded to a server?
No. The entire comparison runs in your browser using client-side JavaScript. Neither text is uploaded, logged, or stored anywhere other than optionally in your own browser localStorage, which keeps your last two inputs so the page is still useful if you reload it. Clearing both panes clears that saved copy. Because nothing leaves the machine, the tool is safe for contracts, internal documents, unreleased copy, and configuration files that you would not want passing through someone else server.