Skip to content
FindTool

    Text Diff

    Compare two blocks of text and highlight every added, removed and changed line.

    Text Diff tool

    Paste two versions above, then press Compare.

    What this tool does

    Put two versions side by side and it marks every line that was added, removed or edited, with line numbers from both. Inside an edited line it highlights the individual words that changed, so a one-character difference in a long line does not need reading twice.

    There is a unified view as well, using the + and - prefixes you already know from git diff, and that view is what the copy button produces — handy for pasting into a ticket or a review comment.

    Common uses

    • Comparing two config files — a working .env against a broken one is the fastest way to find a missing variable.
    • Checking what a formatter, a minifier or a code generator actually changed.
    • Diffing two API responses. Format both with the JSON formatter and sort the keys first, or you will see reordering rather than real differences.
    • Reviewing an edited paragraph with no version control — a contract clause, a translated string, a list where you need the entries present in only one side.

    A short example

    Comparing these two:

    port: 8080          port: 8080
    workers: 4          workers: 8
    driver: memory      driver: redis
                        timeout: 30

    gives two modified lines and one addition:

      port: 8080
    - workers: 4
    + workers: 8
    - driver: memory
    + driver: redis
    + timeout: 30

    In the side-by-side view those first two pairs appear as single rows with only 4/8 and memory/redis highlighted.

    How the comparison works

    The engine finds the longest common subsequence of lines — the largest set appearing in both versions in the same order — and treats the rest as inserted or deleted. That is the same foundation as diff(1), and it is why the output never drifts out of alignment the way a naive line-by-line comparison does after one insertion.

    Deletions and insertions that land next to each other are then paired. If two such lines are similar enough — measured by how many two-character sequences they share — they become one modified row instead of a delete plus an insert. Merely adjacent, unrelated lines stay apart.

    The ignore options affect only the comparison, never the display: with "ignore whitespace" on, a re-indentation shows as no change, but the text you see is exactly what you pasted.

    Worth knowing

    A moved block is not detected as a move. Line-based diffing has no concept of relocation, so a paragraph cut from the top and pasted at the bottom appears as one deletion and one addition — as it does in Git without --color-moved.

    Identical leading and trailing sections are skipped first, so two 2,000-line files differing in one place compare instantly. When the genuinely different region is larger than roughly 2,000 × 2,000 lines, the tool says so and shows it as one replaced block rather than freezing the tab. Comparing smaller sections then gives an exact result.

    Frequently asked questions

    Why does git show a different diff for the same two files?

    Git defaults to the Myers algorithm plus an indent heuristic, on by default since Git 2.14, which shifts hunk boundaries to the more readable line; --histogram and --patience pick different but equally valid common subsequences. Any of them is correct provided applying the result reproduces the second file exactly. What varies is only which lines each one decides to call unchanged.

    Why is every single line marked as changed?

    Almost always line endings or a byte-order mark. If one file was saved with Windows CRLF endings and the other with LF, no line matches exactly, so the comparison is honest but useless. A stray U+FEFF at the start of one file spoils the first line only. Turn on ignore whitespace to confirm the diagnosis, then fix it properly in the extra-space remover.

    Why does a minified file show up as one huge change?

    Because a line-based comparison has nothing to align on. A minified bundle or a single-line API response is one line, so any difference anywhere in it marks that line — the entire file — as one modified row. Format both sides first: the JSON formatter for payloads, or any formatter that puts one declaration per line for stylesheets. The change then localises to a handful of rows.