Skip to content

Text Diff

Ignore

Diff

+0 -0 · 0 unchanged
Left
    Right

      Estimates for educational purposes — not financial, medical, or legal advice. See terms.

      A diff shows you what changed between two pieces of text. The use cases are familiar: comparing two versions of a config file, reviewing a colleague’s edits to a document, checking what the formatter did to your code. The mechanics are surprisingly simple — find the longest sequence of lines that appears in both texts, in order; everything else is an addition (only in the new) or a deletion (only in the old).

      This tool runs that algorithm entirely in your browser, with side-by-side and unified views, and three ignore-options for the cases where exact line equality is too strict.

      How LCS line-diff works

      The longest-common-subsequence algorithm finds the longest sequence of lines that appears in both inputs in the same order — not necessarily contiguous. For example, comparing [a, b, c, d] against [a, x, c, y], the LCS is [a, c]. The lines b and d are removals; x and y are additions; a and c are unchanged.

      The algorithm builds a DP (dynamic programming) table where each cell stores the LCS length up to that position, then walks backwards from the bottom-right to assemble the diff. Memory is O(N × M) — the cap at 5000 lines per side keeps it bounded.

      Side-by-side vs unified view

      Side-by-side shows two columns, with empty placeholder rows where one side has an addition or deletion the other doesn’t. Easy to scan when changes are localized.

      Unified is the format git diff produces: a single column with +, -, and (space) prefixes per line. Easy to copy into a pull request, commit message, or code review comment. The “Copy as patch” button gives you the unified form regardless of which view is active.

      The three ignore-options

      Ignore case lowercases both sides before comparing. Hello and hello become equal.

      Ignore leading/trailing whitespace trims each line before comparing. Useful when indentation changed but content didn’t (a common after-formatter scenario).

      Ignore all whitespace runs collapses every internal whitespace sequence to a single space. foo bar and foo bar and foo\tbar all become equal. Use when whitespace is purely formatting noise.

      The original text is always preserved in the display — only the comparison key is normalized. So Hello and hello show in the diff with their original casing even when ignore-case is on.

      Example: reviewing a refactor

      You refactored a module and want to see what actually changed before pushing. Paste the old version on the left, the new version on the right. The header shows +12 -8 · 154 unchanged — twelve lines added, eight removed, the rest unchanged. Switch to unified view, copy as patch, paste into the PR description.

      Example: comparing two config files

      You’re debugging a deployment difference between staging and production configs. Paste both. Most of the diff is whitespace and key-order changes — turn on ignore all whitespace runs and the diff drops to two real differences: a database hostname and a feature flag. Easy to act on.

      Common mistakes

      Comparing two completely unrelated texts. The algorithm runs fine, but the diff will be one long sequence of removals followed by additions — not useful. The tool is for comparing related-but-different texts (versions of the same file, edits to a paragraph), not for searching one text for content in another.

      Expecting word-level highlighting within changed lines. This is a line-level diff. A changed character renders as the entire old line removed and the entire new line added. Word-level diffs are useful for prose but require a separate algorithm (and a lot more UI).

      Pasting one giant pre-formatted JSON blob. If your input is a single line of JSON, the diff has nothing to work with line-by-line. Run it through a JSON formatter first (the JSON formatter tool does this), then diff the formatted output.

      Forgetting trailing-newline differences. A file ending in \n has an empty final line. If one input has a trailing newline and the other doesn’t, you’ll see a phantom add or remove of an empty line at the end. Either normalize before pasting, or just ignore that one line in the result.

      What this tool does not do

      It does not produce a 3-way merge. For resolving merge conflicts, use a dedicated merge tool (git mergetool, IDE conflict resolver) — 3-way merge requires the common ancestor as a third input.

      It does not handle binary diffs. Binary files need byte-level diffing and a hex view; this tool is text-only.

      It does not show inline character-level highlights within changed lines. The whole line is colored as added or removed; sub-line precision needs a different algorithm. For a single “how similar are these two strings?” number rather than a line-by-line view, use the similarity percentage checker; for the longest shared block of text, the longest common substring finder is the companion.

      Frequently asked questions

      How does the diff algorithm work?

      It's the standard longest-common-subsequence (LCS) algorithm — the same one git diff uses (well, git uses a Myers variant, but they produce equivalent line-level results for normal inputs). The tool builds a DP table of length-of-common-subsequence at each position, then walks backwards to assemble the equal/add/remove segments. For inputs above ~1000 lines per side, expect a brief delay; the tool caps each side at 5000 lines to keep memory bounded.

      Why does my single-character change show as remove + add?

      This is a line-level diff — every line is either equal, added, or removed. A within-line change like 'foo' → 'foo!' shows as the original line removed and the modified line added. Word- and character-level diffs (highlighting just the changed characters) are common in IDE diff viewers but are an entirely different algorithm and add a lot of UI complexity. For most use cases — code review, config comparison, text editing — line-level is what you want.

      What does 'ignore all whitespace runs' do?

      It collapses every run of whitespace (spaces, tabs, mixed) into a single space before comparing, so 'foo bar' and 'foo\tbar' and 'foo bar' all hash to the same key and are treated as equal. The original line text is preserved in the display — only the comparison key is normalized. Use this when comparing reformatted code where indentation changed but content didn't.

      Why is the line count capped at 5000?

      The LCS algorithm uses an N×M DP table. At 5000 lines per side, that's 25 million Int32 entries — about 100MB. Beyond that, browsers start refusing to allocate or freeze for seconds. For larger files, a streaming diff (like git's external Myers) is the right tool. This in-browser tool covers the typical case (config files, short documents, code snippets) without needing a server.

      Is this private?

      Yes. Both texts stay in your browser. The diff runs locally — the algorithm executes in JavaScript with zero network calls. You can verify in DevTools that no requests fire when you compare. Sensitive comparisons (legal contracts, medical records, source code) are safe to paste here.