Diff Checker
Compare two texts and see every addition, deletion, and change highlighted. Line-level and word-level diff modes.
100% private
Compare two blocks of text or code side-by-side with line-level highlighting of additions and deletions — plus a unified-diff view for pasting into a code review comment. Word-level highlighting within a line shows exactly which token changed. Useful for spotting regressions between two log outputs, comparing config files across environments, and reviewing changes when a proper git workflow isn't available. The diff algorithm runs entirely in the browser, so private code can be compared without a remote dependency.
Original
Modified
Runs in your browser
Next steps
Text Diff
RecommendedPaste two texts and instantly see what changed between them.
Code Formatter
RecommendedMake messy code readable — beautify or minify JS, HTML, CSS, YAML, and SQL.
Find & Replace
Find and replace across text with regex support and live preview.
Text Cleaner
Fix messy text in one click — remove extra spaces, normalize quotes.
Runs right inside your browser tab. No uploads. Your files stay private.
What Is a Diff Checker?
A diff checker computes the minimum set of edits that transforms one text into another and visualizes those edits as additions, removals, and unchanged passages. The classic algorithm is Eugene Myers' 1986 O(ND) longest-common-subsequence diff - the same algorithm GNU diff, git diff, and most code-review tools use under the hood.
This tool uses jsdiff (the "diff" npm package by Kevin Decker), the canonical JavaScript implementation of the Myers algorithm. It powers the diffs you see in CodeSandbox, the Algolia search comparison views, GitLens for VS Code, and countless other tools. It's mature, battle-tested, and ships at around 30 KB minified - small enough to run directly in your browser without a network round-trip.
Two granularity modes are exposed. diffLines, the default, treats each line as a token and reports line-level adds and removes - the right view for code review, configuration changes, and any text where line breaks carry semantic meaning. diffWords splits at word boundaries (with whitespace as separators) and is better for prose, comparing two drafts of a paragraph, or spotting a single inserted word inside a long line. The tradeoff is speed: word-level diff has to compare many more tokens, so on multi-thousand-line inputs you'll feel the slowdown.
Display switches between unified and split views. Unified is the GitHub / git diff style: one column with + and - markers in the gutter, additions in green, removals in red. Split shows old on the left and new on the right - the style of FileMerge, Beyond Compare, and most desktop merge tools. Unified is denser and better for reading; split is better for resolving conflicts because your eye can match lines horizontally.
Auto-compare runs on a 400 ms debounce after each keystroke once both panels have content. The debounce matters because diffLines on a 1,000-line file takes 5-15 ms but doing it on every keystroke would still feel laggy. The debounce time is short enough to feel instantaneous and long enough to skip wasted work mid-typing.
The patch download produces a simplified diff format with + / - / space prefixes per line, suitable for human reading. It is not a true unified diff with hunks - it's missing the @@ -line,count +line,count @@ headers that git apply needs. If you want a real applicable patch, use git diff or jsdiff's Diff.createPatch / createTwoFilesPatch functions. The download is good for archive and review purposes.
Performance limits to know. Myers diff is O((N+M)*D) where D is the number of differences - it's fast when the two texts are mostly the same and degrades when they're mostly different. Comparing two completely unrelated 5,000-line files can take a couple of seconds. For very large inputs (10 MB+) consider line-level only, or pre-process to align unchanged headers so D stays small.
Common Use Cases
01
Pre-PR self review
Paste your branch's code and the main branch's code side-by-side to spot regressions before opening the pull request.
02
Configuration drift audit
Compare staging and production configs (after redacting secrets) to identify what diverged between environments.
03
Document revision tracking
Diff two drafts of a contract, RFC, or blog post to see exactly which words and clauses changed.
04
API response comparison
Compare expected and actual JSON or XML payloads from a flaky integration test to localize the failing field.
Frequently Asked Questions
Line-level diff treats each line as an atomic unit - if any character on a line changes, the whole line is marked added/removed. Word-level diff splits on word boundaries and pinpoints the exact words that changed inside a line. Use line-level for code, word-level for prose or single-line edits.
Unified shows both old and new in one column with +/- gutter marks, like git diff or a GitHub PR view. Split shows old on the left and new on the right, like FileMerge or Beyond Compare. Split is easier for visual side-by-side comparison; unified is denser and better for narrow screens.
The diff library implements Eugene Myers' classic O(ND) longest-common-subsequence diff algorithm from his 1986 paper. It's the same algorithm git diff and GNU diff use as their default, so the results are functionally equivalent to what your version control tool would produce.
Out of the box, whitespace differences are reported as real differences - a line with a trailing space is not equal to a line without one. The library has options to ignore whitespace (diffTrimmedLines) but they are not exposed in the UI here. To pre-trim, run both inputs through a normalize step in your editor first.
No. The comparison runs in JavaScript inside your browser tab. Inputs and outputs never reach a server, no analytics record what you pasted, and the data is gone when you close the tab.
Yes - the Patch button downloads a simple +/- prefixed listing as a .patch file. It's human-readable but not a true unified diff with hunks, so git apply won't consume it directly. For an applicable patch, run git diff against your repo or use jsdiff's createTwoFilesPatch in code.
Myers diff time grows with the number of differences. Two near-identical 10,000-line files diff in milliseconds; two completely different ones can take seconds because the algorithm has to consider many more edit paths. Drop to line-level mode and trim long unchanged regions if you need speed.
No - it diffs as text. Two JSON documents with the same content but different key order will appear different. For structural JSON diff, use a tool like json-diff or pre-sort both files with jq -S before pasting.
No. The tool expects plain text. For binary comparison (images, PDFs, executables) use a binary diff like xxd | diff or a content-aware tool like ImageMagick's compare for images.
It's the count of lines (or words, in word mode) that are identical between original and modified. Together with Added and Removed it gives you a quick sense of how big the change is - 5 added, 3 removed, 200 unchanged is a small targeted edit; 100 added, 100 removed is a rewrite.
Advertisement
What's next?