Compare two pieces of text or code with line + word-level highlighting. Side-by-side or unified, ignore-whitespace, ignore-case — entirely in your browser.
No. The whole tool is JavaScript that runs inside this page. The diff algorithm (longest-common-subsequence) runs on your CPU and the result is rendered directly into the DOM. Open DevTools → Network and watch — no requests fire during diffing. Safe to paste internal code, customer data, contract drafts, or anything else you wouldn't want a server tool to log.
First we split both inputs into lines and run an LCS (longest common subsequence) algorithm. Lines that match across both sides are marked equal. Lines that don't match are paired into 'change' rows when an addition appears next to a deletion. For each paired change, we run a second LCS on the line's words (split by whitespace) so only the actual edited words light up red/green — not the whole line.
A clean, fast text diff playground without ads, popups, or third-party trackers — built for developers, writers, and anyone needing to spot what changed.
Switch between split (two columns, classic IDE feel) and unified (single column with +/− markers) with one click. Both views render line numbers and highlight every change inline.
When two lines change, we run a second word-level diff so only the actual differences glow — not the whole line. Easier to spot a single typo in a 200-character line.
Toggle whitespace and case sensitivity to filter out cosmetic changes (re-formatted indentation, capitalisation tweaks) and focus on real edits.
Both texts stay in your browser tab. The diff algorithm runs locally in JavaScript. Verifiable in DevTools → Network: zero requests fire while you type.
See how many lines were added, removed, and modified at a glance. One click copies the diff to your clipboard for pasting into a code review or commit message.
After the page loads, every byte is computed locally. Works on a plane, behind a corporate firewall, or with no network at all — useful for confidential code reviews.
The maths under the hood is older than the web — a 1965 algorithm called LCS, plus a 1986 refinement by Eugene Myers.
Both inputs are broken on \n (or \r\n). Each line becomes a token. We compare tokens — not characters — because most edits in real-world code or documents add, remove, or modify whole lines.
The Longest Common Subsequence is the largest set of lines that appear in the same order in both inputs. We fill a DP table walking from bottom-right; each cell holds the LCS length from that position to the end. This takes O(m × n) time and memory.
Starting from the top-left of the table, we walk forward: if the two current lines match, output an equal; otherwise pick whichever direction (right or down) preserves the LCS length, outputting a delete or insert. The result is a sequence of operations that turns Original into Modified.
When a delete is followed by an insert, we pair them as a change row. To highlight just the parts that differ within the line, we run the same LCS algorithm a second time on the words of each side, splitting on whitespace boundaries.
Real situations where you'll reach for a diff checker.
GitHub's diff view is great, but sometimes you want to see only the substantive changes without the formatter noise. Paste both versions, toggle Ignore whitespace, and the cosmetic re-formats vanish — leaving only the logic edits.
Lawyers and ops teams often need to know what changed between v1 and v2 of a contract. Paste both, get a coloured diff with word-level highlighting — no Word, no Track Changes, no upload of confidential terms to a third-party server.
Ran a sed/awk/Python regex over a config file? Paste the original and the result here to confirm the script edited only what you expected. The character-level highlight catches stray edits a quick visual scan misses.
Translation pair (source vs translation, or two translations of the same source) — the word-level diff makes it trivial to find a missing word, a duplicated phrase, or a punctuation flip that proofreaders missed.
Texts you compare are usually private: code from internal repos, contract drafts, customer-data exports, or unreleased product copy. Pasting them into a stranger's server creates a paper trail you don't control. iKit's diff checker is JavaScript already loaded in your browser tab — the comparison runs on your CPU and never touches a network socket.
Deep-dive tutorials and tool comparisons from the iKit blog.
Pretty-print, validate, and structurally diff messy JSON — when each one is the right tool.
Compare the best Markdown editors of 2026; pair with the diff tool for tracking documentation changes.
No. The whole tool is JavaScript that runs inside this page. The diff algorithm (longest-common-subsequence) runs on your CPU and the result is rendered directly into the DOM. Open DevTools → Network and watch — no requests fire during diffing. Safe to paste internal code, customer data, contract drafts, or anything else you wouldn't want a server tool to log.
First we split both inputs into lines and run an LCS (longest common subsequence) algorithm. Lines that match across both sides are marked equal. Lines that don't match are paired into 'change' rows when an addition appears next to a deletion. For each paired change, we run a second LCS on the line's words (split by whitespace) so only the actual edited words light up red/green — not the whole line.
Split view shows the two texts side by side with paired line numbers — closer to how diff appears in IDEs (VS Code, JetBrains). Unified view shows one column with +/− prefix lines — closer to what `git diff` prints. Pick whichever matches your workflow; both render the same data.
Re-formatting code (running Prettier, switching tab/space, normalising line endings) adds visual noise that buries the real changes. Toggling 'Ignore whitespace' collapses runs of spaces/tabs into a single space and trims line edges before diffing — so you only see the meaningful edits, not the cosmetic ones.
The LCS algorithm uses O(m × n) memory where m and n are line counts on each side. iKit caps the comparison at ~4 million cells (≈16 MB), which comfortably handles a few thousand lines vs a few thousand lines. For larger diffs (entire database dumps, full-file logs), use a CLI tool like `diff` or `git diff --no-index` — those use a smarter algorithm (Myers diff) that scales to millions of lines.