Code Diff Checker — Compare Code Online
Compare two versions of a file line by line, side-by-side or inline, with added and removed lines highlighted. Keyword colouring for JavaScript, Python, HTML, CSS and JSON. 100% client-side — your code stays private.
What is a code diff? A code diff compares two versions of a file and reports which lines were added, which were removed and which are unchanged. This tool matches the two sides with a longest common subsequence, so identical lines stay paired even when blocks move, and only real differences are marked. Results are shown side by side or inline, and can be copied or saved as a .patch file.
How to Use the Code Diff Checker
- Paste the original on the left — The left panel is the baseline — the committed file, the last known-good config, the version you are diffing away from. Any plain text works; nothing is parsed or executed, so the input does not have to compile.
- Paste the modified version on the right — The right panel is the "after". The two sides do not need the same number of lines, and a completely empty panel is valid — it reports the other side as entirely added or entirely removed.
- Choose the language — JavaScript, Python, HTML, CSS, JSON and Plain Text only change how tokens are coloured. They never change which lines are matched, so switching language cannot change the diff itself.
-
Pick side-by-side or inline — Side by Side gives two numbered columns, removals on the left and additions on the right. Inline stacks everything into one column with
-and+prefixes, which reads better on a narrow screen or in a screenshot. - Set the ignore toggles before comparing — Ignore Whitespace trims leading and trailing spaces from every line. Ignore Blank Lines drops empty lines outright, so the line numbers shown afterwards are positions in the filtered text rather than in your original file.
-
Compare, then copy or download — Compare renders the diff and the added / removed counters. Copy Diff puts a plain-text listing on the clipboard; Download Unified Diff saves the same listing as
diff.patchwith--- a/originaland+++ b/modifiedheaders.
How the Comparison Works
Both panels are split on newline characters and compared as two lists of lines. The matching itself is a longest common subsequence (LCS), computed with the classic dynamic-programming table: for inputs of m and n lines the tool fills an (m+1) by (n+1) grid in which every cell holds the length of the longest run of identical lines found in the prefixes up to that point.
dp[i][j] = a[i-1] === b[j-1] ? dp[i-1][j-1] + 1 : max(dp[i-1][j], dp[i][j-1])Walking back through that grid from the bottom-right corner recovers the longest set of lines the two versions still share; everything off that path is a difference. Because the match is computed across the whole file rather than line against line, moving a function twenty lines down still leaves the surrounding code paired up instead of flagging the entire remainder of the file as changed. The cost is memory: the table has one cell per pair of lines, so two 2,000-line files mean four million cells. Comparing whole large files in a browser tab will be slow, and the tool is happiest with the section you actually care about rather than an entire vendored bundle.
Three line states, not four
Every line ends up in exactly one of three states: equal (present in both and drawn on both sides), removed (in the original only) or added (in the modified only). There is deliberately no separate "modified" state, because line-level LCS has no way to tell a rewritten line from an unrelated pair. A one-word edit is therefore reported as one removal plus one addition, and the two rows appear one above the other rather than side by side on the same row. Read the added and removed badges as the real totals — they are counted directly from the result list.
What the language selector actually colours
Highlighting is applied after the diff, purely for readability. Each language is a small set of regular expressions run over the escaped text of a line; there is no parser, no syntax tree and no error checking, so a keyword that appears inside a string or a comment can still pick up keyword colour. That is cosmetic and never affects which lines are matched.
| Language option | Tokens that get colour |
|---|---|
| JavaScript | Keywords such as const, function, class, import, return; quoted strings; numbers; // comments |
| JSON | The same rule set as JavaScript, which covers true, false, null, quoted strings and numbers |
| Python | Keywords such as def, class, lambda, yield, except; quoted strings; numbers; # comments |
| HTML | Tag names after < or </, and attribute names immediately before = |
| CSS | Class and id selectors before an opening brace, plus common property names such as color, margin, display |
| Plain Text | Nothing — lines are HTML-escaped and shown exactly as typed |
Whitespace and Blank-Line Options
Both toggles are applied to the two line lists before the comparison runs, which means they change the rendered output as well as the match.
- Ignore Whitespace trims the leading and trailing spaces and tabs off every line. It does not collapse runs of spaces inside a line, so
a = 1anda = 1are still different. Because the trimmed lines are the ones drawn, the diff appears without its original indentation while the option is on — useful when a reformat has shifted an entire block by two spaces and you only want to see the real edits. - Ignore Blank Lines removes empty and whitespace-only lines from both sides entirely. They disappear from the output too, and the line numbers count filtered lines, so they will not line up with the numbers in your editor. Turn it off when you need numbers you can jump to.
Both options are read when you press Compare. Copy Diff and Download Unified Diff re-run the comparison on the raw contents of the two panels, so an exported diff always reflects the untouched text, whitespace and blank lines included.
Exporting the Result
Copy Diff produces a plain-text listing in which unchanged lines are indented by two spaces, removed
lines start with - and added lines with + . It pastes cleanly into a ticket, a chat
message or a code review comment without any HTML or colour markup coming along with it.
Download Unified Diff writes the same three-way listing to a file called diff.patch,
prefixed with the familiar --- a/original and +++ b/modified header lines and using
single-character markers. It is a readable, attachable record of the change, but it lists the whole file rather than
hunks and carries no @ range headers, so treat it as documentation rather than as a patch to feed to
git apply. When you need an appliable patch, generate it with git diff or
diff -u against the real files.
Pressing Compare also writes both panels into the page address as query parameters via
history.replaceState, which is what lets a reload or a bookmark restore the comparison. The rewrite happens
entirely in the browser and no request carries your code, but the address bar will contain it — clear the panels before
you share or screenshot that URL if the snippets contain credentials, customer data or unreleased work.
Frequently Asked Questions
Side by side draws two numbered columns: the original on the left with removed lines shaded red, the modified on the right with added lines shaded green, and blank filler cells where one side has no counterpart. Inline puts everything in a single numbered column and marks each line with a leading - or +. The underlying diff is identical — only the layout changes — so pick inline for narrow screens and side by side when you want to read both versions of a block at once.
No. The comparison works on whole lines, and a line either matches or it does not. Changing a single character marks the whole line as removed and its replacement as added, without highlighting the specific token that moved. For prose or single paragraphs where word-level detail matters more than line structure, the Text Diff tool is the better fit.
It trims leading and trailing whitespace from every line before comparing, so a block that was re-indented no longer shows up as changed. It does not normalise whitespace inside a line: total = a + b and total = a + b remain different lines. Note that the trimmed text is also what gets drawn, so the diff loses your indentation on screen while the option is switched on.
No. The file is split, compared and rendered by JavaScript in your tab, and no request is made with your content — the page works offline once loaded. One caveat: pressing Compare copies both panels into the page URL so the comparison survives a reload. That rewrite is local, but the code is visible in the address bar, so clear the panels before sharing or screenshotting the link.
Not reliably. The download carries --- a/original and +++ b/modified headers and the usual space, - and + line markers, but it lists every line of the file instead of hunks and includes no @@ range headers, which patch tools use to locate a change. Use it as a readable record to attach to a ticket, and produce a real patch with git diff when you need one that applies.
Because the diff has no modified state. An edited line is emitted as a separate removal and a separate addition, and that counter only increments where a removed entry is directly followed by an added one in the result list — an ordering the matcher does not produce, since additions are emitted ahead of the removals they replace. The added and removed badges are counted directly and are the ones to read.
The LCS table holds one cell for every pair of lines, so memory and time grow with the product of the two line counts: two 500-line files are instant, two 5,000-line files mean 25 million cells and the tab will visibly stall. If you are comparing whole generated files, minified bundles or lock files, trim to the region you care about first, or use a command-line diff which uses a linear-space algorithm.
Use this tool when the text layout matters: source files, templates, config in any format, or anything where you want to see the lines as written. Use JSON Diff when both sides are valid JSON and you want differences reported by path, since it parses first and treats reordered keys or reindented output as no change at all.
Use Cases
Checking a Conflict Resolution
After hand-editing a merge conflict, paste the pre-merge file and your resolved version to confirm you kept the changes you meant to keep and did not silently drop a hunk from the other branch.
Comparing Staging and Production Config
Drop the two environment files in side by side to see exactly which keys differ before a release — the case where an environment-only value has quietly become an environment-only bug.
Reviewing a Snippet Outside the Repo
When a colleague pastes a function into chat and asks "what changed?", compare it against the version on your machine without creating a branch, a stash or a scratch commit to run git diff against.
Auditing a Deployed File
Compare the file you pulled off a server against the copy in source control to prove a hotfix was applied — or to find the manual edit somebody made on the box and never committed.
Reviewing Generated Output
Run a code generator, a formatter or a build step twice and compare the output to see whether a tooling upgrade changed anything beyond formatting before you commit thousands of lines you did not write.
Teaching a Change in a Lesson
Show a class the before and after of a refactor in one screen, using inline mode so the whole diff fits a projector and every added and removed line carries its own marker.