infoOverview

Spotting what actually changed between two versions of a config file, a paragraph, or a pasted log is slow and error-prone when you're just scanning by eye. This tool runs a line-by-line diff on whatever you paste and renders the result as a color-coded, side-by-side comparison — added, removed, and modified lines are immediately visible, without needing a local git checkout or a diff viewer plugin.

Spotting what actually changed between two versions of a config file or document by eye is error-prone — it's easy to miss a single flipped character. Because the comparison runs entirely in the browser, you can pinpoint exactly what changed without ever sending either version to a server.

checklistHow to Use

1. 1Paste the original (before) text into the Original Text field.
2. 2Paste the updated (after) text into the Modified Text field.
3. 3Click Compare to render the Diff Result, with the Original and Modified panels highlighted according to the Added/Modified/Removed legend.
4. 4Use the clear button to wipe both fields and start over.

Note: the diff is computed line by line, so very long lines or mismatched line breaks can make the result harder to read. Running both texts through a formatter first to normalize line breaks tends to make the comparison much clearer.

menu_bookSpecifications & Glossary

• Diff algorithm (LCS): Built on the Longest Common Subsequence (LCS) algorithm — the same family of algorithm behind tools like the classic Unix diff and Git's default diff engine. It identifies the longest sequence of lines common to both texts, then reports everything else as an addition or deletion relative to that shared backbone.
• Line-level diff: Comparison happens at the line level, not the word or character level — a single edited word still marks the whole line as modified. This keeps results easy to scan for config files and prose, though it won't pinpoint the exact word that changed within a long line.
• Highlight legend: Added (green) marks lines present only in the modified text, Removed (red) marks lines present only in the original, and Modified marks lines that exist in both but changed — the same red/green convention used by Git and most code review tools, so the result should feel familiar.
• Side-by-side layout: Original and Modified are shown in two parallel panels rather than the interleaved +/- lines you'd get from a unified diff (the ---/+++ format used by `diff -u` or `git diff`). It takes more horizontal space, but it's easier to read when you want to compare the "before" and "after" of a line at a glance instead of reconstructing it from additions and deletions.
• Diff result structure: Each line is classified into one of four states — unchanged, added, deleted, or modified — and the Diff Result card pairs the original and modified text for that line so you can see exactly what changed without cross-referencing two separate documents.
• Case sensitivity: comparisons are case-sensitive. Text and text are treated as different lines and will show up as a diff even though the only difference is capitalization.
• Line ending handling: differences in line-ending style (LF vs. CRLF) are also treated as part of the line boundary, so two texts that are otherwise identical can still show up as a diff if their line endings don't match.

lightbulbUse Cases

• Sanity-checking a snippet's changes before opening a pull request, when you don't have the file in a local git checkout.
• Diffing two versions of a YAML, JSON, or .env config file before deploying a change.
• Proofreading a document and tracking exactly which sentences changed between drafts.
• Worth knowing if you're used to GitHub: a PR's "Files changed" tab adds word-level highlighting inside a changed line, on top of the line-level diff. This tool only does line-level comparison, so a single-word edit in an otherwise long line will mark the entire line as Modified rather than underlining just the changed word. For quick line-by-line sanity checks that's usually enough; for fine-grained word diffs on prose, pair this tool with your editor's inline diff view.
• Comparing an old and new draft of a translation without losing the line-by-line correspondence between source and translated text.

quizFAQ

Can this show differences at the character or word level?

No. This tool is built specifically for line-by-line comparison, so it won't highlight which word or character changed within a line. If a line is heavily rewritten, the whole line is simply marked as changed.

Are files flagged as different just because of line-ending style (LF vs. CRLF)?

Yes. Line-ending style affects how line boundaries are interpreted, so a file using CRLF and one using LF can show up as different even when the content is otherwise identical. Normalize line endings in your editor before comparing if this is an issue.

Is the comparison case-sensitive?

Yes. Lines that differ only in capitalization, such as Hello versus hello, are still flagged as changed. There's currently no option to ignore case.

Is there a limit to how large a text I can compare?

Texts up to a few thousand lines compare at a practical speed, but extremely large inputs can slow down the in-browser computation and make the display sluggish. For very large files, extract just the section you need before comparing.

Is the text I enter sent to a server?

No. The diff is computed entirely in client-side JavaScript, so nothing you type is ever transmitted to an external server — it's safe to compare even sensitive documents.

Do whitespace-only differences show up in the diff?

Yes. Trailing or leading spaces, and differences between tabs and spaces, count as a change even if that's the only difference on the line. A sudden flood of diffs after an indentation change is usually caused by this.