テキスト差分

A text diff takes two snapshots of the same content — an "old" version and a "new" version — and renders the differences between them so a human can verify what changed. It does not understand the meaning of the text; it operates strictly on lines (or characters), marking which ones are present in one side but not the other. That neutrality is its biggest strength: anything that can be written down as text can be diffed the same way, whether it is documentation, configuration, prompts for an LLM, copy for a marketing page, or a transcript of a chat.

Why eyeballing two versions side by side is not enough

Manual comparison breaks down once the documents are more than a few dozen lines, or once the edits include reordered sections, deleted blocks, or whitespace cleanup. The eye is good at noticing wording differences in adjacent lines and very bad at noticing a missing line in the middle of a long block. A diff tool levels the field by marking every line that is not present on both sides, so you stop trusting your peripheral attention and start trusting a checklist.

How a line-based diff decides what "changed" means

A line-based diff treats each line as an atomic unit. It looks for the longest sequence of lines that appears in both sides in the same relative order, calls that the unchanged backbone, and reports everything else as additions or removals. That is why two visually similar files can produce very different diffs: small changes in line structure can shift what the algorithm treats as the common backbone.

• A line that exists on both sides at corresponding positions is unchanged.
• A line that exists only on the right (new) side is an addition.
• A line that exists only on the left (old) side is a removal.
• A "modified" line is conceptually one removal plus one addition placed next to each other — the algorithm does not have a special "change" verb of its own.
• Reordering one block to another position usually shows up as a delete in one place plus an add in another — not as a move.

Rule of thumb: a diff tells you what the algorithm believes changed line-by-line. It cannot tell you whether the change is meaningful — that is still your job.

このツールの使い方

1. Prepare representative two versions of plain text, config fragments, notes, or generated output in テキスト差分 instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate a visible diff showing added and removed lines, and review line breaks, whitespace-only changes, reordered sections, and whether the diff should be reviewed as text rather than structured data before deciding the result is ready.
3. Only copy or download the result after it fits copy review, release-note checks, config comparisons, prompt revisions, and support-ticket evidence and no longer conflicts with this constraint: For structured formats such as JSON, use the matching structured diff tool when key-level changes matter.

テキスト差分 の例

この例は、テキスト差分 が想定している入力の形と、自分の作業に使う前に確認しておきたい結果の見え方を示しています。

入力例

Before: timeout=30
After: timeout=45

期待される出力

- timeout=30
+ timeout=45

A copy edit, shown as a line-level diff

# old
Welcome to the launch.
Doors open at 6 PM.
Please bring a printed invitation.
Refreshments will be served.

# new
Welcome to the product launch.
Doors open at 6:30 PM.
Refreshments and drinks will be served.

# diff
- Welcome to the launch.
+ Welcome to the product launch.
- Doors open at 6 PM.
+ Doors open at 6:30 PM.
- Please bring a printed invitation.
- Refreshments will be served.
+ Refreshments and drinks will be served.

Notice that "removed: please bring a printed invitation" is an isolated delete — there is no matching addition. The diff highlights it precisely because that single line is easy to miss visually.

Where a text diff is the right tool

Text diff is at its best when the content does not have to follow a strict structure but still needs careful review. The list below is where a quick paste-and-compare almost always saves time.

• Reviewing a copy edit on a landing page, email, or press release where every word matters.
• Confirming a colleague's edits in a config file or environment template before merging.
• Comparing two prompts (or two prompt revisions) for an LLM to understand why outputs differ.
• Verifying that a search-and-replace really only touched the intended occurrences, not their neighbours.
• Auditing what changed between two versions of a transcript, meeting note, or audit log.

Pitfalls that make a diff misleading

A diff is only as useful as the input you give it. The most common cause of a confusing diff is not a bug in the algorithm but a mismatch between what you wanted to compare and what the tool actually compared.

• Trailing whitespace and invisible characters: lines that look identical can differ by a single space or a BOM and show up as changed.
• Different line endings: CRLF (Windows) vs LF (Unix) will mark every line as changed if the tool does not normalise them.
• Reflowed paragraphs: when an editor wraps long lines into shorter ones, a line diff explodes even though the wording is identical.
• Encoding differences: UTF-8 vs UTF-8 with BOM, or different normalisation forms for accented characters, can cause silent mismatches.
• Comparing a fragment against a full document: if you accidentally include or exclude a header, the entire backbone shifts and the diff becomes unreadable.

Text diff vs other comparison strategies

実用上の注意

• テキスト差分 は既定でブラウザ内で動作するため、別のツールチェーンを用意せずにすばやくローカル確認を行えます。
• 実際の入力が大きい、機密性が高い、または業務上重要な場合は、まず代表的なサンプルから始めてください。
• 本番環境、顧客向け、法務、財務、安全性が重要な作業に使う前に、最終結果を必ず確認してください。

テキスト差分 の参考情報

テキスト差分 は、入力の整理、繰り返し可能な変換、公開向け出力を説明します。

• 長いテキストを処理する前に、空白、改行、句読点、見えない文字を確認してください。
• 重要な文章を置換、並べ替え、重複除去、比較する場合は、まず小さなサンプルで試してください。
• 生成された slug、HTML、比較結果は公開前に確認してください。

参考資料

• Unicode Standard Annex #15: Unicode Normalization Forms
• MDN: String