本文へスキップ
DevTools / テキスト差分

テキスト差分

Comparing two versions of a file is routine until the changes are small and the file is large, at which point a character-level view is the only one that answers the question. This diff runs entirely in your browser, supports line, word and character granularity, renders both a unified patch and a side-by-side view, highlights the changed span within a modified line rather than marking the whole line, and can normalise case and whitespace so that reformatting does not drown out the real edits.

すべてブラウザ内で実行 — 何もアップロードされません。

Original
Changed

仕組み

The underlying algorithm computes a longest common subsequence between the two inputs, then derives the shortest edit script from it — the minimum set of insertions and deletions that turns one text into the other. Running it at line granularity first is what makes the output readable: a paragraph that was reflowed produces one changed line rather than two hundred changed characters. Changes are classified as equal, inserted, deleted or replaced, and the counts of each are summarised so you can see the scale of an edit before reading it.

Intra-line highlighting is a second pass. When a line is classified as replaced, the old and new versions of that line are themselves diffed at word granularity, and the differing spans are emphasised inside the line. Without this, a single changed character in a long line marks the entire line as changed and tells you nothing. With it, the edit is visible immediately. The same pass is what makes a config change reviewable: a line where one port number changed shows the two numbers highlighted and nothing else.

Granularity is a real choice, not a cosmetic one. Line diffing is right for source code and configuration, where line structure carries meaning. Word diffing handles prose that has been reflowed, because the line breaks are noise. Character diffing is for the cases where a single byte matters — a hash, a key, an encoded blob — and is the only setting under which a one-character change in a long token is visible at all. Switching granularity re-runs the comparison without needing the input again.

Ignoring case and whitespace is a normalisation applied before comparison rather than after, so the two texts are canonicalised and then diffed. That is what makes a reformatted file show no changes and a genuine edit show up clearly. The trade is that the highlighted output shows the normalised text, so a change that consists only of capitalisation will appear as no change at all. Turn the options off when the whitespace or the case is the thing you are checking.

主な利用シーン

  • Compare two versions of a config file to find what changed between environments.
  • Check whether two API responses differ, and if so exactly where.
  • Verify that a formatter or transpiler changed nothing semantically in a file.
  • Compare two long tokens or keys character by character to find a typo.
  • Review a list of values that was edited by hand to confirm only the intended entries changed.
  • Produce a unified diff to paste into a code review or a bug report.

最終更新: 2026-10-14 — 本文は英語で表示されます（UI は翻訳済み）。

よくある質問

Is my text uploaded to a server?

No. The comparison runs entirely in JavaScript in your browser and no part of either input is transmitted — you can confirm this by opening your browser's network panel while the diff runs. That matters because text diffing is disproportionately used on things that should not be sent anywhere: private keys, licence files, environment configurations and customer data extracts.

Line, word or character — which should I pick?

Line for source code, configuration and logs, where the line is the unit of meaning. Word for prose, especially prose that has been rewrapped, since line breaks there are artefacts of the editor rather than content. Character for tokens, hashes, keys and any short string where one byte is the whole difference. If a diff looks unreadably noisy, the granularity is usually the reason rather than the data.

How large a file can it handle?

Comfortably, a few hundred kilobytes of text per side. The comparison is quadratic in the worst case — the pathological input is two long texts with nothing in common — but real-world inputs share structure and run much faster. For megabyte-scale files, a command-line diff is a better tool, and for binaries a hash comparison is the right approach since a textual diff of binary data is meaningless.

Why do reformatted files show so many changes?

Because indentation and trailing whitespace are real characters and a line-by-line comparison sees them. Two options fix it. Turning on ignore-whitespace treats runs of spaces and tabs as equivalent, and switching to word granularity sidesteps line structure entirely. Run the tools formatter on both sides before comparing if the goal is to review semantic changes in a file that was also reformatted.

関連ツール