Paste two texts to compare line-by-line and character-level differences.
Both views show the same diff — they differ only in layout. Choose based on how you process changes.
| View | Best for | How it looks | Use when |
|---|---|---|---|
| Side-by-side | Code review, config comparison | Original left, modified right — aligned row by row | You need to mentally map what changed where. Scan both versions at once. |
| Unified | Patch files, commit diffs, compact reading | Single column — deletions (−) above additions (+), context lines around each hunk | Reading changes sequentially. Familiar if you use git diff or GitHub PR reviews. |
Pro tip: The unified view uses the same format as git diff output and GitHub pull request reviews. If you read a lot of PRs, unified will feel immediately familiar.
This tool uses the Longest Common Subsequence (LCS) algorithm — the same core algorithm used by Git, GNU diff, and most version control systems.
LCS finds the largest set of lines that appear in both texts in the same order, without requiring them to be adjacent. Those matching lines become the "unchanged" context. Every line not in the LCS is either an addition (exists only in the modified text) or a deletion (exists only in the original).
Original: cat → Modified: car
| Original char | Modified char | LCS match? | Result |
|---|---|---|---|
| c | c | ✓ yes | unchanged |
| a | a | ✓ yes | unchanged |
| t | — | no | deleted |
| — | r | no | added |
The char-level diff applies the same LCS logic within a single changed line — finding matching characters and highlighting only the ones that differ. This is why enabling char-level highlighting lets you spot a single renamed variable in a 200-character line without scanning the entire thing.
Time complexity is O(m × n) where m and n are the number of lines (or characters, for char-level). For two 1,000-line files, that is 1 million operations — fast enough to complete in under 50ms on a typical device.
The colour and marker system is consistent across both views:
The line numbers in the gutter refer to the original line numbering, not the diff output position. This lets you navigate back to the exact line in your editor or file without counting.
If the diff shows more changes than you expect — or marks everything as changed — one of these four causes is almost always responsible.
// Windows file (copied from Notepad) const x = 1; const y = 2;
// Unix file const x = 1; const y = 2;
Every line shows as changed even though the text looks identical. Windows uses \r\n (CRLF); Unix uses \n (LF). Most editors strip \r on paste, but terminal copy or curl output may not. If every line shows as changed, line endings are the culprit. Paste into a plain-text editor first and save as LF.
function greet(name) {
return "Hello " + name;
}function greet(name) {
return "Hello " + name;
}A line with two trailing spaces differs from one without — the diff correctly marks it as changed. Auto-formatters (Prettier, Black, gofmt) strip trailing whitespace, so a formatted file will always differ from an unformatted one. Enable "show whitespace" in your editor to spot these before comparing.
redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
redirect_uri=https://example.com/callback
A percent-encoded URL and its decoded equivalent look different to the diff algorithm — every %2F differs from /. Decode both versions to the same form before comparing. Use the URL decoder tool to normalise them first.
{"name":"Alice","age":30,"city":"London"}{
"name": "Alice",
"age": 30,
"city": "London"
}Minified JSON on one side, pretty-printed on the other: every line differs because the structure changed, not the data. Pretty-print both versions first using the JSON formatter tool before running the diff.
It uses the Longest Common Subsequence (LCS) algorithm — the same family of algorithms used by Git, GNU diff, and most professional diff tools. LCS finds the largest set of matching lines between two texts, then marks everything not in that set as added or removed. Time complexity is O(m × n) where m and n are line counts. For typical files under 1,000 lines, results are near-instant.
Side-by-side shows the original text on the left and the modified text on the right, with changed lines aligned horizontally. Unified view shows a single column where deleted lines are prefixed with − and added lines with +, with a few context lines above and below each change. Unified is the format git diff outputs; side-by-side is easier for scanning large structural changes.
When a line is modified (not simply added or deleted), char-level diff highlights the exact characters within the line that changed. For example, if you changed "colour" to "color", the deleted u is highlighted in the original line and the surrounding characters are shown normally. This prevents you from scanning entire changed lines looking for the one character that differs.
The most common cause is line endings. Windows text uses \r\n (carriage return + line feed) while Unix/macOS uses \n only. When you copy text from a Windows file or terminal, the \r characters come along and make every line appear different. Paste the text into a plain-text editor, save as UTF-8 with Unix line endings (LF), then paste again. Trailing whitespace is the second most common cause.
Context lines are unchanged lines shown above and below each changed block. They give you the surrounding code or text so you can understand the change in context — without reading the entire file. The default is 3 context lines (matching git diff's default). Use the settings panel to increase context to "show all" or reduce it to 1 line for a more compact view.
Yes. The diff tool operates on plain text, so it works with any programming language, markup, or data format — JavaScript, Python, Go, Java, SQL, YAML, JSON, HTML, CSS, XML, Markdown, and more. For JSON specifically, format both sides consistently first (use the JSON formatter tool) to avoid false differences from whitespace.
No. All comparison happens in your browser using JavaScript. The text never leaves your device and is never sent to any server. You can disconnect from the internet after loading the page and the tool will continue to work.
The LCS algorithm runs in O(m × n) time. For two 1,000-line files, that is 1,000,000 operations — well within browser limits. For very large files (10,000+ lines), performance depends on your device. There is no hard limit enforced by the tool. If you are comparing large files regularly, a local tool like diff, git diff, or VS Code's built-in compare may be faster.