Paste version A on the left, version B on the right, and see exactly what changed. No git clone, no IDE, no signup. Runs entirely in your browser.
A free, in-browser tool for diffing two versions of code without opening Git, GitHub, or your IDE. Paste the old version on the left, the new version on the right, and the differences highlight character by character. The text never leaves your machine, which matters when the snippet is from a private repo or an unmerged branch.
It is built for the moment a colleague drops two versions of a function in Slack and asks "what changed?". Spinning up a local checkout for a 12-line diff is overkill. So is opening the GitHub PR view if you don't have the PR yet. Two text panes, one diff, done in fifteen seconds.
This is not a replacement for git diff on a real working tree. It cannot stage hunks, apply patches, or run blame. What it can do is the part you actually need most often: take two arbitrary blobs of text and show you the edits between them. Underneath, the diff itself is the same engine that powers our compare-text tool, framed for code review.
The diff runs character by character, then a semantic cleanup pass groups the changes back into readable chunks so the highlight lands on a renamed identifier rather than every individual letter inside it. Insertions on the right pane render in green; deletions on the left pane render in red. The two panes scroll-lock together, so when you find a change at line 80 on one side, the other side jumps with you.
Why character-level instead of line-level? Because for short snippets the line-only view is too coarse. Renaming a single variable from id to userId is one identifier change; a line-level diff would show you the whole line as deleted plus a whole new line inserted, which is technically true but makes the actual edit harder to spot. Character mode plus semantic cleanup highlights the renamed token and leaves the rest of the line alone. For long files the trade-off flips, which is why classic line-based diff is what Git uses by default. Both have a place. This tool gives you the snippet-friendly view.
What the tool deliberately does not do: it is not syntax-aware. It does not parse JavaScript, Python, or Java. A reformatted block with the same semantics will still show as a diff, because to a text comparator it is different text. If you want format-aware diffing for structured payloads, our compare-json page does that for JSON, compare-yaml for YAML, and compare-xml for XML and POM files. For raw source code, the text diff plus your own eyes is usually faster than configuring a syntax-aware tool for a one-off snippet.
Two text panes, one diff. No login, no upload, no patch format to parse.
Copy the old version of the function, file, or snippet from your editor, terminal, or wherever it lives. Ctrl+C then paste into the left pane. If you are pulling from git show <commit>, copy the body of the file rather than the patch header so the diff only highlights actual code changes.
Do the same with the new version. If a colleague pasted it in Slack, Teams, or email, copy from there directly. Whitespace and indentation are preserved on paste, which matters for languages where indentation is significant like Python and YAML. Tab vs spaces will show as a difference if the two snippets disagree.
Deletions show as red strikethroughs on the left; insertions show as green on the right. The change counters in each header tell you how many distinct edits were detected. Read through the highlights, focus on logic changes first (control flow, conditionals, error handling), and treat pure rename or formatting changes as lower priority on the review pass.
Someone drops two code blocks in chat and asks which one is right. Cloning the repo, switching branches, and opening your IDE for a 20-line snippet is wasted effort. Paste both into the diff tool and you have an answer before the next message lands. This is the single most common reason people reach for an online diff.
CI pipelines, Dockerfiles, package.json, and GitHub Actions workflow YAML drift constantly. A teammate edits .github/workflows/ci.yml on a branch, the build breaks, and you want to see exactly what changed without checking out their branch. Paste the main branch version next to the broken-branch version and the offending step usually surfaces in seconds. For workflow files specifically, our YAML diff page handles indentation edge cases more cleanly.
Product managers, designers, and account managers sometimes need to know what a code change does without reading a Git interface. A GitHub PR view assumes familiarity with diff syntax, file trees, and review comments. Pasting the before-and-after into a clean two-pane view, then walking through the highlights together, is much friendlier. This is also useful in incident postmortems when the audience includes folks outside the engineering org.
You have git show abc123 output and git show def456 output for a file across two commits, perhaps from a CI log or a remote sandbox where you cannot easily run git commands. Strip the patch headers, paste the two file contents, and diff. This works well when you are debugging on a server, reading a build artifact, or reviewing a security advisory that quotes file contents from two specific commits.
A vendor sends a sample integration in a PDF. A regulator emails a snippet of policy code. A consultant attaches a patched version of your script. None of these come as a clone-able repo. Copy the text from the PDF or email, paste it next to your current version, and you have a usable review surface in under a minute. Expect some formatting noise from PDF copy-paste; line breaks and quote characters are the usual culprits.
The cases where a plain text diff disagrees with what Git, your IDE, or your code review tool would show. Worth scanning before you paste production code in and worry about a false positive.
| Topic | What this tool does |
|---|---|
| Line endings (CRLF vs LF) | Windows-style CRLF and Unix-style LF are different bytes. A file pasted from a Windows editor and a file pasted from a Linux container will show as a full-file diff if the line endings disagree, even with identical visible text. Git normalises this with core.autocrlf; this tool does not. |
| Trailing whitespace | Spaces or tabs at the end of a line will show as a difference. Git's core.whitespace can warn or auto-fix on commit; here, what you paste is what you compare. If a code review noise floor is full of trailing-whitespace edits, strip them in your editor before diffing. |
| Binary files | This tool is text-only. Pasting the contents of a binary file (a PNG, a compiled JAR, a sqlite DB) will produce nonsense or hang the tab. For binary diff, Git shows "Binary files differ" rather than a patch; you need format-specific tooling for the actual content. |
| .gitattributes text vs binary marking | A repo's .gitattributes can override Git's text-vs-binary detection per file pattern. That setting does not travel with a copy-paste. If you suspect a file is being treated differently across two checkouts, that file is the place to look; this tool will diff it as plain text regardless. |
| Character vs line diff | This page uses character-level diff with semantic cleanup. Git defaults to line-level, with optional git diff --word-diff for word-level. Character-level is best for short snippets where a single token changed; line-level is best for long files where lots of lines changed wholesale. |
| git diff --word-diff | Git's --word-diff mode highlights word-level changes inside a line, which is closer to what this tool does for snippets. The output format is different (terminal-friendly markup vs side-by-side panes), but the intent overlaps. If you live in the terminal, --word-diff is the local equivalent. |
| Large file thresholds | Browser-based diffs are responsive up to a few thousand lines on each side. Beyond that, semantic cleanup gets slow and the rendered DOM gets heavy. For huge files, run git diff locally and pipe to a pager, or break the comparison into smaller sections. |
| Encoding (UTF-8 only) | The diff assumes UTF-8 input, which covers almost all source code in 2026. Files saved as UTF-16, Windows-1252, or Shift-JIS may show as mojibake on paste depending on your browser. If a snippet looks scrambled, re-save the source file as UTF-8 before copying. |
Local git diff compares two refs (commits, branches, the working tree) inside a real repository. It knows about your index, your worktree, and your history. This online tool does none of that. It compares two arbitrary blocks of text you paste in. Use git diff for real review work on a checked-out repo. Use this when you have two snippets and no convenient way to land them in a working tree, or when you want a side-by-side view without context-switching.
Not exactly. GitHub and GitLab use a line-based unified diff with file context, hunk headers, and per-file summaries. This tool uses character-level diff with semantic cleanup, which is better for short snippets and worse for diffing entire files across many changes. For a real pull request review go to the GitHub PR view. For a fast snippet comparison outside the PR, this is faster and does not require navigating to the right repo.
No. This is a plain text diff. It does not parse the language, so it cannot tell that a renamed variable is the same identifier in 12 places, and it cannot ignore reformatted whitespace the way a syntax-aware diff would. For most snippet review this is fine because you read the highlights with your own brain. If you need true semantic diffing for code, your IDE (VS Code, IntelliJ) or a tree-sitter-based diff is the right tool. This page optimises for speed, not deep parsing.
The classic Unix diff -u command produces a unified-format patch (the same format Git uses internally). It is line-based and designed to be machine-readable so you can apply the patch elsewhere. This tool is human-readable. It shows two side-by-side panes with inline highlighting rather than a single column of plus and minus lines. It does not produce a patch file you can apply with git apply or patch -p1. If you need to generate a patch, use the command line. If you need to read a diff, this is friendlier.
Yes, but on its own terms. CRLF (Windows) and LF (Unix) line endings will show as a difference if the two pasted snippets disagree, because they technically are different bytes. Trailing whitespace likewise. This is consistent with how Git treats files when core.autocrlf is off. If you only care about logic changes and not whitespace, trim each pane before pasting. We do not currently offer a "ignore whitespace" toggle, though it is on the roadmap; git diff -w is the local equivalent.
Practically yes. The diff runs in your browser, so very large inputs (think a full vendored library or a 50,000-line generated file) will slow the page or stall the tab depending on how much memory your browser has. For typical code review work (functions, files, build scripts, configs up to a few thousand lines on each side) the diff completes effectively instantly. If you need to compare entire repositories, a real Git tool or a folder-comparison tool is the right answer; this page is built for snippets and single files.
Your code never leaves your browser. The diff, the highlighting, and the rendering all run on your machine. We do not upload the text, log it, or pass it to any third-party service. This matters specifically for proprietary code review: pasting an unreleased feature, a security patch, or a snippet from a private repo into a cloud service can itself violate your employer's data-handling policy. Verifying the claim is straightforward. Open your browser's DevTools, switch to the Network tab, paste both versions, and watch. There are no outbound requests when you compare. The same privacy model holds across our other tools, including compare-text, compare-json, and compare-yaml. Code review works best when the review surface is trustworthy.