Diff Checker

Paste two versions of a file and see exactly what changed — added lines in green, removed lines in red. Everything runs locally in your browser.

Results will appear here…

What Is a Diff?

A diff is a line-by-line comparison between two versions of a text file. The name comes from the classic Unix diff utility, and the concept is at the heart of every version control system — Git's git diff, GitHub pull requests, and code reviews all display changes as diffs. Being able to read a diff quickly is one of the most practical skills a developer can build.

Common Uses

How the Comparison Works

The tool splits both inputs into lines and finds the longest common subsequence (LCS) between them. Lines present in both versions are shown as context, lines only in the "Original" box are marked as removed, and lines only in the "Changed" box are marked as added. This is the same core algorithm behind the GNU diff tool, scaled down to run entirely in your browser — your text never leaves your device.

FAQ

Q: Does this tool upload my code anywhere?
No. All comparison happens locally in your browser with JavaScript — nothing is sent to a server. This makes it safe to paste proprietary source code or confidential configs.
Q: Can it compare binary files or images?
No — this tool works with text only. For binaries, use a dedicated binary diff tool or compare file hashes (e.g. md5 or sha256) to detect changes.
Q: How large can the inputs be?
The comparison handles typical source files (up to a few thousand lines) instantly. Extremely large files may slow down the in-browser algorithm — for those, the command-line diff or git diff --no-index is a better fit.
Q: Why does the whole file show as changed when I only edited one line?
Almost always line-ending mismatch: Windows files use CRLF (\r\n) while Unix/Mac use LF (\n). If the two versions use different line endings, every line counts as changed. Normalize both sides first — in VS Code click "CRLF" in the status bar and switch to "LF", or run dos2unix on the file — then re-compare. Trailing whitespace differences can cause the same symptom.
Q: Can it ignore whitespace, indentation, or case differences?
No — the comparison is exact: a line that gained one leading space or changed case counts as a changed line. That strictness is deliberate, since reformatted code and re-indented YAML are real changes you usually want to see. If you only care about content and not formatting, run both sides through a formatter (Prettier for JS/JSON, yaml.dump for YAML) before pasting, so identical content renders identically.
Q: How do I do the same comparison in the terminal or in Git?
For files on disk: diff -u old.txt new.txt prints a unified diff. For two files that aren't in a repo: git diff --no-index old.txt new.txt (add --color-words for word-level highlighting instead of line-level). For changes already committed: git diff HEAD~1 or git diff main..feature — but mind the dot count, main..feature (two dots) compares the two branch tips, while main...feature (three dots) compares from the shared merge-base, which is what a GitHub pull request actually shows. The browser tool is handy when the text lives in chat, a log viewer, or a CMS and you don't want to save temp files first.
Q: Can I compare two JSON responses and ignore key order?
Not directly — the comparison is line-based, so two objects with the same data but reordered keys show up as fully changed lines. Normalize both sides first: jq -S . old.json > old.sorted.json sorts keys alphabetically (repeat for the new file), then compare the two sorted copies. In Python, json.dumps(obj, sort_keys=True, indent=2) achieves the same thing. Once key order and indentation match, everything left in the diff is a real data change rather than formatting noise.
Q: What does \ No newline at end of file mean in a diff?
It is not an error — it is the diff telling you that one side's last line has no terminating newline. POSIX defines a text file as a sequence of newline-terminated lines, so a file that ends mid-line is technically malformed, and the marker is printed right after the line it applies to (on the removed side, the added side, or both). It matters because the marker sits outside the line's content: adding a trailing newline to an otherwise untouched file shows as one changed line even though every character of text is identical, and some editors and patch implementations will glue the last line to the next file's first line. Fix it once with printf '\n' >> file.txt or sed -i -e '$a\' file.txt, and set insert_final_newline = true in your editor config so it stops coming back. Here in the browser the equivalent symptom is a line that looks unchanged but counts as changed — check whether one box ended with a newline and the other did not.
Q: How do I diff a minified file or a very long single line?
Line-based comparison gives you almost nothing there: a minified bundle is one enormous line, so a one-character change paints the entire thing as removed and added. Two workarounds. First, pretty-print both sides before comparing — npx prettier --parser babel, jq . for JSON, or the "Format Document" command in your editor — so the change lands on its own line. Second, compare at word or character level: git diff --word-diff=color (or --word-diff-regex=. for character granularity), and on macOS git diff --no-index --word-diff a.js b.js works outside a repo too.

Two Git-Specific Blind Spots

Q: Why does git diff show nothing when I know I changed files?
Because plain git diff compares the working tree against the index only. If you already ran git add, those edits are staged and moved out of that comparison — use git diff --cached (or git diff HEAD to see everything at once). Untracked, brand-new files never appear in any git diff output at all; git status is what lists them.
Q: A file I moved shows as deleted + added, hiding the real edits. How do I fix that?
That's rename detection: Git guesses renames from content similarity, and it only inspects the diff after a certain threshold. Force it with git diff -M (or tune it, -M40%), and add --stat to see a similarity index 98% line instead of a whole-file delete plus whole-file add. If the two "sides" are already pasted into the boxes above, compare the moved file's old and new copies directly — the reorder noise disappears and only the genuinely edited lines remain.

Why Use Our Diff Checker?

No signup, no file uploads, no server round-trips. Paste, compare, and copy the result — the color-coded output makes it obvious what changed at a glance, and the diff summary tells you how many lines were added and removed before you even scroll.