Text & Writing

Free Text Diff Checker Online

Compare two blocks of text and see additions, deletions and changes highlighted.

What is a text diff?

A diff — short for "difference" — is a representation of the changes between two versions of a text. Given an original text and a modified version, a diff algorithm identifies which lines were deleted, which were inserted, and which remained the same. The result is displayed as a structured comparison that lets you understand exactly what changed, without reading both texts in full.

Diffs are fundamental to software development. Every commit in Git is stored as a diff. Code reviews on GitHub, GitLab, and Bitbucket display diffs to show what a pull request changes. Patch files distributed on mailing lists are diffs in unified format. Documentation teams use diffs to review edits to technical writing. Database administrators compare configuration files between environments. Journalists compare document versions to track revisions. The ability to quickly identify the difference between two texts is one of the most universally useful operations in knowledge work.

This tool brings that capability to your browser — no command line required, no files to save, no installation. Paste any two pieces of text and see a colour-coded, line-by-line comparison instantly.

How the diff algorithm works

This tool uses the LCS (Longest Common Subsequence) algorithm — the same foundational approach behind the Unix diff command, Git's diff engine, and virtually every code review tool in existence.

The algorithm works in two phases. First, it builds a dynamic programming table that finds the longest sequence of lines common to both texts — the lines that appear in the same relative order in both versions and therefore didn't change. Second, it backtracks through that table to reconstruct the edit script: the minimal sequence of insertions and deletions needed to transform the original into the modified version.

The key property of an LCS-based diff is that it finds a minimal edit: it never marks a line as changed if it could be considered equal. This means the diff output is as small as possible and highlights only genuine differences, not artefacts of the comparison algorithm.

Example unified diff output
   const greeting = "Hello";
−  console.log(greeting + " world");
+  console.log(`${greeting} universe`);
   return greeting;

Unified vs split view: which to use

Unified view

Like git diff in terminal

Both texts are merged into a single scrollable panel. Removed lines appear in red prefixed with "−", added lines in green prefixed with "+", unchanged lines in grey. Context is immediately visible — you can see what surrounded each change without switching panels. Best for small-to-medium diffs where you want to understand the full picture quickly.

Split view

Like GitHub code review

Original text is displayed on the left, modified on the right, with corresponding lines aligned. Deleted lines show on the left with a red background; inserted lines show on the right with a green background. Empty rows fill gaps where one side has more lines than the other. Best for large block-level changes where you want to compare sections side by side.

Common use cases for developers

Config file comparison

Compare nginx.conf, docker-compose.yml, or .env files between production and staging environments. Instantly see which keys differ without reading thousands of lines.

API response changes

Paste a JSON response from two API versions and diff them to detect breaking changes. Tip: use the JSON Formatter first to normalise indentation so formatting differences don't appear as content changes.

SQL query optimization

Compare the original query with your optimized version to confirm you haven't accidentally changed the logic while restructuring the SQL. Useful for complex CTEs and multi-join queries.

Documentation editing

Compare a draft document with the revised version to review edits before publishing. Shows exactly which sentences were rewritten, deleted, or added.

Log file analysis

Diff application log snippets from two time periods to identify what changed between a working state and a failure. Good for spotting new error patterns.

Code review prep

Before opening a pull request, diff your changes locally to review what you're about to submit. Helps catch accidental debug code, forgotten TODOs, or unintended whitespace changes.

Understanding ignore whitespace and ignore case

Two lines that are semantically identical can appear as changed if they differ only in formatting or capitalisation. The ignore options let you focus on meaningful differences:

Ignore whitespaceEquivalent to: diff -w or git diff -w

Lines are compared after trimming leading and trailing spaces and collapsing internal whitespace runs to a single space. A line re-indented from two spaces to four spaces, or with a trailing space added, will be treated as unchanged. The displayed output still shows the original formatting — only the comparison logic changes. Essential when comparing code that was auto-formatted or pasted from different editors.

e.g. "  function foo()" equals "function foo()"

Ignore caseEquivalent to: diff -i or git diff --ignore-case

All characters are lowercased before comparison. Useful for comparing SQL (where keywords may be upper or lower case), HTML attribute names, HTTP headers, or config keys that are case-insensitive in their target system.

e.g. "Content-Type" equals "content-type"

How to read the diff output

The unified diff format has been the standard since the 1980s and is used identically by Unix diff -u, git diff, patch files, and this tool. Once you learn to read it, you can read any diff anywhere:

Prefix	Colour	Meaning	Line numbers shown
−	Red	Line was deleted — exists in Original only	Original line number
+	Green	Line was inserted — exists in Modified only	Modified line number
	Grey	Line is unchanged — exists in both versions	Both line numbers shown
⋯	—	Separator — hidden unchanged lines in between	—

The "Hide unchanged" toggle collapses unchanged lines and shows only a few lines of context around each group of changes — exactly like git diff in a terminal. This is useful when a small change is buried in a large file: you don't need to scroll through hundreds of unchanged lines to find it.

Tips for effective text comparison

Normalise JSON before diffing

JSON files with different indentation or key ordering will produce noisy diffs full of false positives. Run both JSON texts through the JSON Formatter (Prettify mode, same indent setting) before pasting them into the diff tool. This ensures only actual value changes appear as differences.

Use line-level ignores for auto-formatted code

If your team uses Prettier, Black, or gofmt, a reformatting commit will produce a diff with hundreds of changed lines where only indentation moved. Enable "Ignore whitespace" to filter those out and see only the logical changes.

Compare encoded strings after decoding

If you're diffing URL-encoded strings or Base64 payloads, decode them first using the URL Encoder / Decoder or Base64 Encoder / Decoder. Diffing encoded text is often meaningless — a single character change in the raw string can alter many characters in the encoded form.

Copy diff for sharing

The "Copy diff" button copies the output in standard unified diff format — the same format used in Git patches and bug reports. Paste it into a GitHub comment, Jira ticket, or Slack message and it will be immediately readable to any developer.

How Git uses diffs internally

Git does not store file snapshots for every commit — that would consume enormous storage. Instead, Git stores the objects (blobs) for each version of a file and computes diffs on demand when you run git diff or view a commit. Each commit object points to a tree of blob hashes, and the diff is computed by comparing the blob content of matching file paths between two commits.

Git's default diff algorithm is Myers diff, the same algorithm described by Eugene Myers in 1986. For most text, it produces optimal diffs. Git also supports the patience diff algorithm (--diff-algorithm=patience) which produces more readable diffs for code by anchoring around unique lines — particularly useful when a function is moved rather than modified. The histogram diff (--diff-algorithm=histogram) is an evolution of patience diff and is often recommended for code review workflows.

git diff

Shows unstaged changes — what is in the working directory but not yet staged for commit.

git diff --staged

Shows staged changes — what will be included in the next commit. Alias: --cached.

git diff HEAD~1 HEAD

Shows what changed between the previous commit and the current one.

git diff main...feature

Shows changes in the feature branch since it diverged from main — the "what did this PR change" view.

git diff -w

Ignores whitespace-only changes. Equivalent to the "Ignore whitespace" option in this tool.

git log -p

Shows commit history with the full diff for each commit inline — useful for auditing a file's change history.

Your text never leaves your browser

The entire diff computation runs in JavaScript inside your browser tab. Nothing you paste is transmitted to any server, logged, or stored. This makes the tool safe to use with confidential code, internal documents, unreleased content, and sensitive configuration data — the same level of privacy as running diff locally on your own machine.

FAQ

Common questions

What is a text diff and how does it work?

A diff (from "difference") compares two versions of a text and identifies which lines were added, removed, or remain unchanged. This tool uses the LCS (Longest Common Subsequence) algorithm — the same core approach used by Git, Unix diff, and most code review tools. It finds the largest set of lines common to both texts, then marks everything else as an insertion or deletion.

What is the difference between unified and split view?

Unified view shows both texts merged into a single panel — deletions (red, prefixed with −) and insertions (green, prefixed with +) are interleaved in the order they appear. Split view places the original text on the left and the modified text on the right, aligned line-by-line, which makes it easier to see what changed in each specific area. Both views show the same information; split view is generally more readable for large changes.

What does "ignore whitespace" do?

When enabled, lines are compared after stripping leading/trailing spaces and collapsing internal whitespace sequences to a single space. A line that only differs in indentation or trailing spaces will be treated as equal. The original formatting is still displayed in the output — only the comparison logic changes. This is equivalent to git diff -w.

What does "ignore case" do?

When enabled, uppercase and lowercase letters are treated as identical during comparison. "Hello" and "hello" will be considered the same line. Useful when comparing configs, SQL, or HTML where casing may vary without semantic difference.

Is there a size limit for the texts I can compare?

The LCS algorithm used here is O(n × m) in both time and memory, where n and m are the line counts of each text. For texts up to a few thousand lines each, diffing is instant. For very large files (tens of thousands of lines), the comparison may slow down — in that case, a command-line tool like `diff` or `git diff` is more appropriate.

How do I copy just the diff output?

Click the "Copy diff" button above the output panel. This copies the result in unified diff format — deletions prefixed with "−" and insertions prefixed with "+" — which you can paste into a ticket, Slack message, or documentation.

Can I compare code files with this tool?

Yes. Paste any text — source code, config files, JSON, Markdown, SQL, log excerpts — into the two panels. The tool is language-agnostic. For structured formats like JSON, consider also using the JSON Formatter on this site to normalise indentation before diffing, so formatting differences don't obscure logical changes.

What do the statistics (added/removed/unchanged) mean?

Added = lines that appear in the modified text but not in the original. Removed = lines that appear in the original but not in the modified. Unchanged = lines identical in both versions (after applying any active options like ignore whitespace/case). These counts refer to lines, not characters.

How is this different from running `diff` in a terminal?

Functionally similar — both use LCS-based algorithms and produce the same categories of changes. The key differences are convenience: this tool runs in your browser with no installation, shows colour-coded output, and lets you paste text directly. Terminal diff operates on files, supports more flags, and handles very large files more efficiently. For quick comparisons, this tool is faster; for scripting or automation, use the terminal.