HandyTools Hub

Diff Checker

Compare two texts and highlight differences instantly.

Original Text

Modified Text

The Diff Checker compares two blocks of text and shows exactly what changed — additions, deletions, and inline edits — with side-by-side and unified views. It is built for reviewing a contract revision, spotting what changed between two configuration files, checking an edited paragraph against the original, or confirming that two exports really are identical. Paste both versions and the differences are marked instantly, without uploading either one.

How to Use

  1. Paste the original into the left panel and the modified version into the right panel. Any plain-text content works: code, CSV, JSON, Markdown, or prose.
  2. Choose a comparison level — line, word, or character — depending on what you are reviewing.
  3. Switch the view between split (side by side) and unified (single column with +/− markers) to match how you like to read changes.
  4. Copy or export the result if you need to share what changed with someone else.

Reading the Diff

Every comparison shows three things at once. Deleted content is marked on the original side; added content is marked on the modified side; and unchanged context stays unmarked between them so you can see where each change sits. When a line is edited rather than replaced, the tool highlights the specific words or characters that differ inside the line, which is what separates a useful diff from a wall of red and green.

In unified view, the prefixes do the work: a line beginning with − exists only in the original, + only in the modified version, and a leading space means the line is unchanged context. If you have ever read git diff output, this format will look familiar.

Worked Examples

Example 1 — a config change. Two versions of an nginx.conf differ by one directive. At line level, the changed proxy_read_timeout line is flagged while the dozens of surrounding lines stay context. A reader can approve the change in seconds instead of scrolling both files.

Example 2 — an edited paragraph. A 400-word paragraph gets one sentence reworded. Line-level comparison marks the entire paragraph as changed; switching to word level isolates the six words that actually moved, which is the difference between “this paragraph was rewritten” and “this clause changed” in a contract review.

Example 3 — verifying an export. A data export is regenerated after a schema tweak. Comparing the old and new CSV files confirms that exactly one column was added and no rows shifted — a check that row counts alone would miss.

Choosing a Comparison Level

  • Line — the default for source code, configs, and structured data. It mirrors how version control records changes, so review comments line up with commits.
  • Word — best for prose, documentation, and legal text, where a single reworded phrase matters and the rest of the line is noise.
  • Character — the most precise option, useful for spotting a changed digit in a serial number, an invisible character, or a one-punctuation difference in a translated string.

If a difference seems impossible to find, drop to a finer level: the change is usually smaller than the coarse view suggests. And if two “identical” lines are flagged, suspect whitespace or line endings rather than a real content change.

Common Misunderstandings

  • A move is not a move. Diff algorithms express moved blocks as a deletion plus an insertion, so heavy refactoring produces a noisy diff even when little logic changed.
  • Reformatting dominates. Running a formatter before comparing makes every touched line look changed. Compare the formatted versions of both sides, or ignore whitespace, when you only care about logic.
  • Line endings matter. A file saved with Windows CRLF and the same file saved with Unix LF can appear entirely different. Normalize line endings before comparing files that came from different operating systems.
  • “No differences” is a result. When the tool reports no changes, that is a useful confirmation — the two copies are byte-for-byte identical in the compared units.

The same style of comparison underpins version control. When you run git diff or generate a patch file, the output is a line-level diff in the unified format: unchanged lines carry a leading space, removals a −, additions a +, and a header like @@ -12,7 +12,9 @@ marks where the block sits and how many lines it spans. Practicing here with the unified view makes reading real patches and merge conflicts far easier, because the structure is identical — only the surrounding tooling changes.

Features

  • Side-by-side and unified comparison views
  • Line, word, and character granularity, switchable on the fly
  • Inline highlighting of the exact changed words or characters
  • Clear color coding for additions, deletions, and unchanged context
  • Works with code, configs, CSV, JSON, Markdown, and prose
  • 100% client-side — neither version is uploaded

Frequently Asked Questions

Why does my moved code show as a deletion plus an insertion?

A line-based diff has no concept of moving text. It reports the minimal set of line edits that turns one version into the other, and a move is expressed as a delete at the old position and an insert at the new one. Some tools detect moved blocks heuristically, but the underlying algorithm cannot represent 'moved' as an operation.

Which is better, split view or unified view?

Split view puts the original and the modified text side by side, which suits two documents of similar length that diverged in many places. Unified view interleaves both versions in one column with + and − markers, which reads more like a patch and is usually easier for reviewing a short set of changes.

Should I compare at word level or line level?

Use line level for code, configuration, and any structured file where a line is a meaningful unit — it matches how version control thinks. Use word or character level for prose, where rewording one sentence inside a long paragraph would otherwise mark the whole line as changed and bury the actual edit.

Why are two lines that look identical marked as different?

Invisible differences: trailing spaces, a tab versus spaces, a different line ending (LF versus CRLF), or a non-breaking space instead of a regular one. Turn on the tool's whitespace visibility, or copy each version into a character-level comparison, to see what actually differs.

How large a text can it compare?

Texts of a few hundred kilobytes compare instantly; very large inputs (multiple megabytes) can make the browser slow because the algorithm's cost grows with the amount of difference, not just the file size. For huge files, compare them in a version-control system or a dedicated diff tool instead.

Do the two versions I compare stay on my device?

Yes. The comparison runs entirely in your browser with JavaScript. Neither the original nor the modified text is transmitted to a server, so confidential drafts, contracts, and source files never leave your machine.

Reviewed by the HandyTools Hub team · Last updated