Text Diff Checker

import 'github-markdown-css'

What does the text diff tool do?

This tool compares two blocks of text line by line. Put the old version on the left and the new version on the right, and the page summarizes:

• added lines
• removed lines
• paired changed lines
• unchanged lines

The implementation is optimized for readable line-level review, not character-level highlighting. It first aligns content with a longest common subsequence (LCS) pass, then pairs nearby remove and add chunks into changed rows when possible. That makes it useful for copy review, config changes, logs, and API snapshots.

The tool also normalizes and to , so text copied from different operating systems is compared on the same newline basis.

Good fits

• reviewing API response snapshots
• checking copy revisions
• auditing config edits
• comparing prompt versions or log excerpts

References

• GNU diffutils Manual
• Git diff
• Longest common subsequence

How to use it

1. Prepare two text blocks

• Left Before: the old or baseline version
• Right After: the new or target version

Paste any multi-line content, such as copy, logs, config fragments, or API payloads.

2. Read the summary cards

The page updates in real time:

• added: lines that exist only on the right
• removed: lines that exist only on the left
• changed: remove/add pairs grouped as modifications
• unchanged: exact matches

3. Review the table

The result table shows both line numbers and row state so you can quickly see:

• what stayed the same
• what disappeared
• what is new
• what was paired as a change

Recommended workflow

1. Make sure each logical record is on its own line.
2. If your input is JSON, format it first.
3. Read the summary, then inspect the detailed rows.

References

• GNU diffutils Manual
• Git diff
• Longest common subsequence

FAQ

Why is there no character-level highlighting?

Because the current implementation is line-based. It focuses on telling you which whole lines changed rather than which characters inside a line changed.

How is changed produced?

When a diff chunk contains both removed and added lines, the tool pairs them in order and renders the pair as changed. This improves readability but is not a semantic similarity match.

Why can repeated lines look unintuitive?

LCS alignment can have multiple valid answers when many lines repeat. The current implementation chooses one stable path, but it may not always match human expectations.

Do whitespace-only edits count?

Yes. There is currently no “ignore whitespace” or “ignore case” switch.

Can I export patch output or unified diff?

Not today. The tool only provides a visual table plus summary counts.

References

• GNU diffutils Manual
• Git diff
• Longest common subsequence

Example workflows

1. Copy review

Put the old headline or paragraph on the left and the revised version on the right. You can quickly tell whether the update is a light edit or a full rewrite.

2. Config verification

Environment variable lists, YAML fragments, and request option blocks work well when each entry is on its own line.

3. Prompt versioning

When iterating on AI prompts, compare old and new prompts to spot changes in role definition, constraints, or output format.

4. Snapshot review

Format a JSON payload first, then run it through text diff to identify field additions, removals, and rewritten values more clearly.

Suggested combinations

• Format structured data before diffing it.
• Compare timezone results or conversion logs after converting them into line-oriented text.

References

• Git diff
• GNU diffutils Manual
• Longest common subsequence

How the line-based diff works

The tool first splits both inputs into arrays of lines. It then computes a longest common subsequence (LCS) so unchanged lines can be aligned in a stable way. Everything outside that alignment becomes part of a diff chunk, and the chunk is rendered with these rules:

1. exact matches become equal
2. left-only lines become remove
3. right-only lines become add
4. mixed remove/add chunks are paired into change rows in order

That is why this tool is best understood as a readable line-level viewer, not a semantic editor. Large reorders, repeated lines, or tiny character edits inside one line may still produce output that looks more like a traditional diff than a human summary.

Why newline normalization matters

Windows commonly uses CRLF while Unix-like systems use LF. By normalizing line endings first, the tool avoids a large class of false differences caused only by platform conventions.

References

• GNU diffutils Manual
• Git diff
• Longest common subsequence

Practical tips

Preprocess before comparing

Format structured data first, strip irrelevant timestamps from logs, and keep one logical record per line. This reduces noise and makes changed rows easier to interpret.

Watch for false differences

Common sources of visual noise include:

• trailing spaces
• blank line count changes
• indentation differences
• large moved blocks

changed is a readable approximation

The tool pairs removed and added lines in sequence. It does not compute text similarity, so complex rewrites may still need human interpretation.

Split very large inputs

LCS is a classic dynamic-programming approach with non-trivial time and space cost on long inputs. For large documents, compare them section by section.

References

• GNU diffutils Manual
• Git diff
• Longest common subsequence