Text Diff
Compare two texts line by line. Added lines are highlighted green and removed lines red. Useful for comparing config files, logs, and code.
📖 Where people get stuck
Compare two texts and highlight the differences line by line and word by word. Everything runs in the browser and nothing you paste is transmitted. Keep in mind that no visible difference is not the same as identical: two texts that look exactly alike can differ in line endings or invisible characters, and conversely a diff full of changes may represent a single meaningful edit.
| Case | What happens | What to do |
|---|---|---|
| Every line shows as changed | Almost certainly the line endings differ. Windows writes CRLF, macOS and Linux write LF, and neither is visible. Re-saving the same content on a different machine is enough to mark every line as changed. When a Git diff suddenly balloons, this is the first thing to check. |
Normalise both sides to LF with the line ending converter before comparing. As a permanent fix, put * text=auto eol=lf in a .gitattributes at the repository root. The trim-trailing-whitespace-on-save editor setting produces the same class of diff, so agreeing on it across the team saves trouble later. |
| They look identical but do not match | There is an invisible character in there. The usual suspects are a zero-width space (U+200B), a non-breaking space (U+00A0), an ideographic space (U+3000) or a BOM (U+FEFF). They arrive when you copy from a web page, a PDF or Word, and render as an ordinary space or as nothing at all. Mixed full-width and half-width alphanumerics look the same way. | Switch to the word-level view and the offending spot lights up on its own. If you know where it came from, unify the alphanumerics and spaces with half-width and full-width conversion, and when a BOM is the suspect check the encoding with the mojibake diagnosis. When the source is a web page, pasting through a plain-text editor first is the quickest way to avoid the whole problem. |
| A reformat makes the diff unreadable | Re-indenting, reordering keys or running a formatter changes nothing semantically but rewrites every line. Reviewing in that state buries the real change in noise and invites a miss. With JSON or YAML, reordering keys alone is enough to wipe out a line-based diff. | Split the reformat and the real change into separate commits. Being able to say this commit is formatting only is the whole benefit. When you just want to compare structured data, use the JSON diff rather than a line diff — it reports additions, removals and changed values regardless of key order. Alternatively, normalise both sides with the JSON formatter before comparing. |
A diff shows you how the strings differ, not how the meaning changed. A commit that renames a variable everywhere turns the whole file red and green while behaving identically. Conversely, a one-character change from < to <= can alter the behaviour of an entire system. There is no correlation between the size of a diff and the size of the risk — the only reliable pattern is that large diffs get skimmed.
📖 How to Use
-
1
Paste text on both sidesPaste the old version on the left and the new version on the right.
-
2
See the diffAdded lines are highlighted green, removed lines red. Line-by-line comparison.
-
3
Copy as unified diffUse Copy to export as Git-style unified diff — useful for code review comments.
❓ Frequently Asked Questions
Does it support word-level diff?
Can I ignore whitespace?
Is my data sent anywhere?
Any structured diff (JSON/XML)?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.