Code diff checker with unified and split view
Compare two versions of code line by line with numbered unified or side-by-side views, whitespace options, change stats and copyable unified patch output.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
8 lines
9 lines
- Added
- +4
- Removed
- −3
- Unchanged
- 5
- Similarity
- 41.7%
- Hunks
- 1
How to compare two versions of a file
- Paste the original on the left and the changed version on the right. Give each a file name if you plan to export a patch.
- Choose Unified for a git-style view with both sets of line numbers, or Side by side to see the two files aligned.
- Turn on the ignore options to filter out reformatting noise — trailing whitespace is ignored by default because it is almost never a real change.
- Copy the unified patch, or download it as a
.patchfile you can feed togit apply.
Unified or side-by-side?
Unified is denser and matches what you see in a pull request or a terminal, which makes it the better choice for reviewing a change you already understand. Side by side wins when lines have been rewritten rather than added or removed, because you can read the before and after on one row instead of hunting for the matching pair a screen apart. Both views here show line numbers for both files, so a finding can be quoted precisely.
How the diff is computed
The comparison uses Myers' O(ND) algorithm over lines — the same family of algorithm git uses by default. It finds the longest common subsequence of the two files, which is the diff with the fewest inserted and deleted lines. That is why hunks line up with what your version control shows, and why the patch output applies cleanly.
Everything runs in your browser. Proprietary or unreleased source can be compared here without it touching a server, which is the main reason to use this rather than an online diff that posts both files to a backend.
The ignore options
| Option | What it does | When to use it |
|---|---|---|
| Trailing whitespace | Strips spaces and tabs at the end of a line before comparing | Almost always — editors add and remove these invisibly |
| Leading whitespace | Strips indentation before comparing | After a re-indent, or when comparing code that moved into a new block |
| Repeated spaces and tabs | Collapses runs of whitespace to a single space | After a formatter changed alignment padding |
| Letter case | Compares case-insensitively | Comparing SQL, config keys or generated identifiers |
The ignore options only affect matching. The lines shown, copied and exported are always the originals, so a patch produced with whitespace ignored still contains the real bytes.
Reading a unified patch
A unified diff is made of hunks, each introduced by a header of the form
@@ -12,7 +12,9 @@. That means: starting at line 12 of the original, seven lines are
covered; starting at line 12 of the new file, nine lines are covered. Inside the hunk, a leading space
marks an unchanged context line, - a removed line and + an added one.
Context lines are what make a patch resilient. Three lines either side (git's default) let the patch apply even if the surrounding file has shifted a little. Zero context produces the smallest patch and the most fragile one; ten is useful when you want a reviewer to see the whole function.
Applying the patch
Download the file, then run git apply changes.patch from the repository root. If the paths
in the header do not match your working tree, adjust the file-name fields above before exporting, or
apply with patch -p1 < changes.patch. git apply --check tells you whether
it will apply cleanly without changing anything.
Which diff tool do you want?
This page is line-oriented and tuned for source code. For prose — a document where a single paragraph is one very long line, and you care about which words changed rather than which lines — the text diff checker produces a far more readable result. For structured data, format both sides with the JSON formatter (with key sorting on) before diffing, so ordering differences do not drown out the real change.
Questions
How is this different from the text diff checker?
This one is tuned for source code: line numbers on both sides, split view, indentation-aware whitespace handling and unified patch output you can pipe into git apply. The text version focuses on word-level prose changes.
What algorithm does it use?
A Myers longest-common-subsequence diff over lines, the same family of algorithm git uses, so the resulting hunks line up with what your version control would show.
Can I ignore reformatting noise?
Yes. Toggles let you ignore leading and trailing whitespace, collapse runs of internal whitespace, and ignore case, so a re-indent or a lint pass stops drowning out the real change.
Is the patch output valid for git apply?
It is a standard unified diff with configurable context lines and correct hunk headers. Set the two file paths in the header fields and the result applies cleanly with git apply or patch -p1.
Are my files uploaded to compare them?
No. The diff is computed in your browser, so proprietary or unreleased source can be compared without it leaving the machine.