Diff Checker
Compare code or text with line-by-line diff and unified output.
Reviewed by Aygul Dovletova · Last reviewed
How to Use the Diff Checker
- Paste the original file into the left editor. This is treated as the baseline - the "before" state.
- Paste the modified file into the right editor. Everything the tool reports is relative to how this differs from the left.
- Click Compare. The diff panel renders below with line-level additions in green, deletions in red, and unchanged context in gray.
- Read the gutter numbers. Each changed row shows the original line number and the new line number; deleted rows show only the original, added rows show only the new, so you can jump straight to the offending location in your real file.
- Copy as Unified Diff to get a patch in the exact format
git apply,patch, and code-review tools consume. Paste this into a PR comment when inline review comments are not expressive enough. - Use Swap to flip the sides, which is handy for checking "would applying this patch in reverse make sense?" Use Clear to reset both editors.
How the Comparison Works
The checker implements the classic Myers diff algorithm described in Eugene Myers's 1986 paper "An O(ND) Difference Algorithm and Its Variations" - the same algorithm Git has used as its default since day one. It splits both inputs on line breaks, treats each line as an atomic token, and walks an edit graph to find the shortest edit script that turns the original into the modified. The result is a sequence of hunks: contiguous runs of unchanged lines with inserted and deleted lines between them. Output rendering happens in JavaScript without any DOM innerHTML assignments, so pasting lines containing <script> or other HTML-looking text cannot inject markup. The Copy as Unified Diff button wraps each hunk in the canonical @@ -a,b +c,d @@ header used by GNU diff, Git, and Mercurial.
When You Would Use It
- Reviewing a pull request offline where you have the two files on disk but no git history connecting them.
- Comparing two versions of a config file - Nginx, Terraform, YAML - that a teammate mailed you with no context.
- Producing a clean unified diff to paste into a JIRA ticket or a chat channel as proof of what changed.
- Checking that your build-artifact output is byte-identical across two runs by diffing the generated files.
- Verifying that running a formatter (
prettier,gofmt,black) did not introduce unintended content changes on top of formatting. - Spotting the smallest change that caused a regression, by diffing the last green deploy against the first red one.
Common Pitfalls and Edge Cases
- Trailing newline differences. A file with a final newline and one without are not identical; the tool shows this as a change to the last line, matching
diff's "\\ No newline at end of file" marker. - CRLF vs LF. Pasting Windows-style line endings into one side and Unix-style into the other marks every line as changed. Normalize with a tool such as
dos2unixfirst, or expect a sea of red and green. - Tab versus space indentation. Myers diff is line-level and will flag a tab-to-spaces reflow as a full rewrite of every line. Use a whitespace-ignoring tool such as
git diff -wwhen that is the intent. - Very long files. Myers is O(ND) where N is total tokens and D is the edit distance. Inputs of tens of thousands of lines with large D can take several seconds in the browser before anything renders.
- Binary data. Line-based diffs are meaningless on compiled binaries, images, or zipped archives. The tool will still produce output but it is noise.
- Identical files. The output shows the entire file as unchanged gray lines with no hunks - useful confirmation that nothing moved.
Unified Diff Format Background
The unified diff format was introduced by Wayne Davison for GNU diff in the early 1990s and is now standardized de facto across Git, Mercurial, SVN, and every code-review tool. A unified diff opens with two file headers beginning with --- and +++, followed by one or more hunks. Each hunk begins with a header of the form @@ -originalStart,originalLines +newStart,newLines @@, followed by the lines themselves: space-prefixed for context, minus-prefixed for removed lines, plus-prefixed for added lines. By default GNU diff uses three lines of context, which is also the Git default. POSIX 1003.1 standardizes the format, and tools like patch can consume it to re-apply the change elsewhere. This tool's output is byte-compatible with those consumers, so you can copy, pipe to patch -p0, and watch the change land.
Comparison to Alternatives
git diff is the right tool when both sides live in a repository - it knows about renames, handles binary detection, and supports -w for whitespace-insensitive comparison. GNU diff -u is the POSIX workhorse for ad-hoc file pairs on your disk. meld, kdiff3, and Beyond Compare provide three-way merge views that this browser tool cannot match. VS Code's built-in diff editor has syntax highlighting and inline word-level tweaks. Use this web checker when the files are not on your machine yet - you pasted them from Slack, email, or a log viewer - and you just want a unified-diff copy-paste-ready patch without opening a terminal. If your job is a three-way merge or a repo-wide whitespace-ignoring review, reach for the dedicated tooling.
Frequently Asked Questions
Is the algorithm really Myers diff?
Yes. The checker uses the forward-path variant from Eugene Myers's 1986 paper, the same approach Git uses by default (you can switch Git to patience or histogram variants for pathological cases). It produces the shortest edit script, which for most code changes matches what a human reviewer expects.
Does the tool run a server-side diff for large files?
No. The diff function is a plain JavaScript implementation that runs in the main thread of your browser tab. There is no fetch call, no worker offloading, and no backend. For files up to roughly 10,000 lines on each side the diff completes in under a second on a modern laptop. Beyond that you may see a brief UI freeze while the edit graph is walked, but the computation stays local.
Can I round-trip the unified diff through git apply?
Yes, as long as the file headers match what git expects. The Copy as Unified Diff output uses --- a/<filename> and +++ b/<filename> style headers with generic placeholder names. Replace those with the real paths relative to your repo root and the patch will apply cleanly with git apply - or with GNU patch -p1 for non-git workflows. Line-ending mismatches are the single most common apply failure; run dos2unix first if in doubt.
What happens with very large files?
The UI stays responsive until computation begins; once Compare is clicked, the main thread is busy walking the edit graph. For two 50,000-line files with many differences, expect a few seconds of work before the output renders. If you regularly diff files that large, use the terminal git diff --no-index or GNU diff -u, which are written in C and finish instantly.
Why are tab and space versions of the same line flagged as different?
The comparison is byte-exact at the line level. A line reformatted from tabs to four spaces is literally different bytes, so every line marks as changed. That is often what you want when reviewing a security patch, but it is usually not what you want when reviewing a formatter-induced change. Pre-normalize with a tool such as expand, untabify, or prettier before diffing if you want to see only semantic changes.
Does the tool detect moved blocks?
No. Myers diff reports any moved block as a deletion in the old location and an insertion in the new location. Advanced tools (git --color-moved, IntelliJ) highlight relocations in a third color. For large refactors consider a semantic diff like difftastic that parses the source into an AST first.
Is there any privacy concern with pasting proprietary code?
The comparison runs in the same JavaScript sandbox as your page, with no outbound network call carrying the inputs. No analytics pixel captures the textareas, no service worker caches the content, and closing the tab drops everything from memory. That said, clipboard managers on your OS may retain pasted content indefinitely - consider that vector if the files are highly sensitive.
What is the difference between unified diff and context diff?
Context diff is the older format (diff -c), with separate blocks showing before and after lines bracketed by *** and ---. Unified diff (diff -u) interleaves them using -/+ prefixes and a single @@ header per hunk, which is more compact and easier to read. Unified diff won the format war in the late 1990s and is what Git, Mercurial, GitHub, GitLab, and Gerrit all use exclusively.
How is this different from the text-diff tool on this site?
This checker is optimized for file-to-file comparison: line-level Myers diff, unified diff output, side-by-side line numbers, and a monospace font suited to code. The text-diff page targets shorter prose and inline word-level changes, which is better for proofreading and translation review. If your input is code, configs, logs, or any newline-separated content, this is the right page; if you are diffing two paragraphs of English, prefer text-diff.
Can I feed the output to patch on a Mac?
Yes. macOS ships BSD patch, which reads GNU unified diffs fine. Save the diff to a file, cd into the original's directory, and run patch -p1 < changes.diff (or -p0 if headers use root-absolute paths). For GNU patch behavior: brew install gpatch.
More Developer Tools
Base64 Encoder & Decoder
Encode UTF-8 text to Base64 online or decode Base64 back to UTF-8 and plain text. Runs in your browser with no upload.
Open toolBulk URL Encode / Decode
Encode or decode many URLs at once. Paste a newline-separated list and the tool processes each line in parallel, preserving order and blank lines.
Open toolCode Screenshot
Create beautiful code snippet images with customizable themes.
Open toolColor Converter
Convert colors between HEX, RGB, HSL and CMYK formats.
Open toolCron Expression Parser
Parse cron expressions into human-readable schedules with next run times.
Open toolCSS Formatter / Minifier
Format, beautify and minify CSS code.
Open tool