Code Diff Viewer — Free HTML CSS JS Snippet

The insight is that a diff is defined by what did NOT change: find the longest sequence of lines appearing in both files in the same order (the longest common subsequence), and everything outside it is, by definition, the changes — old-only lines are deletions, new-only lines are additions. The dp table computes LCS lengths for every pair of suffixes: dp[i][j] answers "how many lines can old-from-i and new-from-j still have in common?", built bottom-up so each cell needs only its three neighbours. The walk then re-traces the optimal path: when lines match, that line is part of the common spine (context); when they differ, the walk moves in whichever direction preserves the larger remaining LCS, emitting a del or add. Git's Myers algorithm solves the identical problem in O(ND) time and O(N) space instead of this O(MN) table — necessary for huge files, but the table version is the one you can hold in your head, and for the few-hundred-line inputs typical of embedded viewers it is plenty fast.

Line-based diffing has no concept of "modified" — a changed line is literally an old line that disappeared plus a new line that appeared, which is exactly how git stores it. The pairing pass reconstructs the human notion of modification: an unbroken run of deletions immediately followed by additions is almost always an edit, so pairOps zips them positionally into replacement pairs (surplus lines on either side stay as pure adds/dels). For each pair, charDiff finds what actually changed by trimming the longest common prefix and longest common suffix — everything between the trims gets the strong highlight. This heuristic is intentionally simple: for "return data;" → "return data.results;" it isolates ".results" perfectly. Its known weakness is multiple separated edits in one line (it will highlight the whole span between the first and last change); upgrading means running the same LCS algorithm over word tokens within the pair, which the code structure permits — diffLines works on any array, including line.split(/(\W)/).

Skip the algorithm and map the patch format straight into ops. A unified diff's body lines start with a space (context), "-" (deletion), or "+" (addition); hunk headers like @@ -12,6 +12,8 @@ carry the starting line numbers for each side. Parse line by line: maintain two counters seeded from the hunk header, and emit { t: "ctx", a, b, text } incrementing both, { t: "del", a, text } incrementing the old counter, or { t: "add", b, text } incrementing the new one, stripping the prefix character from text. Feed the result through pairOps() and either renderer works unchanged — the renderers only know about ops, not about how they were produced. This is the right architecture for PR-review tools where the server (or git itself) already produced the patch: never re-diff what git has diffed, since byte-identical rendering to git's decisions is what reviewers expect.

Tailwind: the card is bg-slate-900 border border-slate-700 rounded-xl overflow-hidden; gutters are w-10 px-2.5 text-right text-[11px] text-slate-600 select-none border-r border-slate-800 align-top; code cells are px-3.5 whitespace-pre font-mono text-[12.5px]; row tints are bg-green-400/10 for additions and bg-red-400/10 for deletions with the intra-line marks as bg-green-400/30 rounded-sm and bg-red-400/30. In React, keep diffLines, pairOps, charDiff, and collapse as pure functions in a diff.ts module — they have zero DOM dependencies — then const ops = useMemo(() => pairOps(diffLines(oldLines, newLines)), [oldText, newText]) and map ops to <tr> elements, replacing the innerHTML string-building with JSX (which also gives you escaping for free, so drop esc()). In Angular, the same pure module plus a component computing ops in a computed() signal, rendered with @for over the collapsed rows; the hunk-expand becomes a signal flip instead of a re-render call.