Upload your input and generate a TEXT-DIFF result to compare changes and review differences in one output.
- deletions and + additions). Toggle Ignore leading whitespace, Ignore trailing whitespace, or Ignore all whitespace to suppress reformatting noise. Syntax highlighting is available for common languages so the original colors stay readable while diff highlights overlay on top..diff patch.Diffing turns "something changed somewhere" into a precise list of additions, deletions, and edits. Version control, code review, contract redlining, and config auditing all sit on top of this primitive. Doing it in the browser — with no upload — means proprietary code, signed agreements, API keys in configs, or unreleased policy documents never leave the device.
userId -> userID that pure line-diffs flag as a full rewrite.application.yaml, .env, or Terraform plan outputs side-by-side. The Ignore all whitespace toggle suppresses indentation noise so genuine value changes (replicas: 3 -> 4, a new feature flag) stand out.| Mode | What it shows | Best for |
|---|---|---|
| Side-by-side | Two columns, aligned line-for-line, with blank placeholders where one side has only adds or deletes | Refactors and structural changes — easier to read overall shape |
| Inline / unified | Single column, deletions prefixed - and additions prefixed +, matches git diff output |
Small edits, copying into a PR description, applying as a patch |
| Line-level highlights | Marks whole changed lines red/green | High-volume changes — scan a file for the "neighborhood" of edits |
| Character / word level | Highlights only the differing characters or tokens within a changed line pair | Rename-only edits, typo hunting, minor token swaps (== vs ===) |
| Algorithm | How it works | When to pick it |
|---|---|---|
| Myers | Greedy shortest-edit-script search on an edit graph; Git's default since 2006 | General-purpose default — fast, predictable, fine for most files |
| Minimal | Myers plus extra passes to find the smallest possible diff | When you need the absolute fewest hunks for a clean patch |
| Patience | Anchors on unique lines first, then diffs the gaps between anchors (Bram Cohen, 2008) | Refactored code where Myers produces misaligned hunks |
| Histogram | Patience extended with low-occurrence common-element matching (JGit, Shawn Pearce, 2010) | Code with many repeated tokens (braces, blank lines) — a Springer 2019 study found Histogram produced better diffs in 40.3% of files vs 10.9% for Myers |
Diff describes what changed between two texts; merge applies those changes to a third text. A diff is a read-only comparison — you look at it and decide what to do next. A merge takes the diff between a common ancestor and two branches and tries to combine both sets of changes into one file, raising a conflict if the same line was edited on both sides. This tool is diff-only — for merges, use Git's git merge or a three-way tool like Meld, KDiff3, or Beyond Compare.
The most common cause is whitespace — a code formatter or editor "format on save" rewrote indentation, line breaks, or trailing spaces across the file. Enable Ignore all whitespace to mask those changes and see only the semantic edits. The second most common cause is line-ending differences (CRLF on Windows vs LF on macOS / Linux); normalize line endings in both inputs before comparing. The third is structural reformatting (JSON keys reordered, XML attribute order changed) — format both sides identically with JSON Formatter or SQL Formatter before diffing.
Side-by-side is better when you want to understand structure — reading two function definitions next to each other, scanning a refactor, or reviewing a contract clause-by-clause. Inline / unified is better when the change is small and dense (a few typo fixes), when you want to copy the diff into a pull request body, or when you need patch-format output you can paste into git apply. Most reviewers default to side-by-side and switch to inline only to copy a patch.
Yes. Three toggles cover the common cases: Ignore leading whitespace masks indentation changes (handy after a formatter run), Ignore trailing whitespace masks editor cleanup of end-of-line spaces, and Ignore all whitespace collapses every whitespace difference including blank-line additions. This mirrors Git's -b, --ignore-space-at-eol, and -w flags. Note that for languages where whitespace is semantic (Python indentation, YAML structure), Ignore all whitespace can hide real bugs — use the leading/trailing toggles instead.
Both. Diffing is text-mode and treats every line as an atomic unit by default, then runs a second pass to highlight character-level changes within line pairs that pair up. For code, line-based diffs work well because most edits are line-scoped. For prose, the word-level highlighting matters more — a single paragraph rewritten will show as one big change unless the tool tokenizes within the line, which this one does. For contract redlines specifically, run the diff with Ignore all whitespace on so reformatting (line wrapping at different widths) doesn't dominate.
Practical limit depends on the device. Modern desktop browsers handle a few megabytes per side without trouble (~50,000+ lines). Diffs over ~10 MB total or ~100,000 lines start to feel slow because every character-pass and DOM render scales with input size. For multi-megabyte log files or generated code, run git diff --no-index file-a file-b or diff -u locally — those skip the syntax-highlight render pipeline and finish in seconds.
Format both inputs first so cosmetic differences (key order on serialization, indentation, trailing newlines) do not appear in the diff. Use JSON Formatter to pretty-print both JSON inputs with identical indentation, XML Validator to canonicalize XML, or SQL Formatter for SQL dumps. After formatting, run the diff with Ignore all whitespace on for an extra safety margin. For deeply structured comparisons (where you care that a key moved but the value is unchanged), a dedicated JSON diff like jq or json-diff produces cleaner semantic output than a text diff.
No. The diff runs entirely in the browser — the original and modified texts, the file uploads, the algorithm, and the rendered output never leave the device. This matters for source code under NDA, signed contracts, configs containing API keys or DB passwords, and personal documents. Closing the tab discards the input; nothing is persisted unless you explicitly download the patch.
The default is Myers, which is also Git's default. For most diffs the result is identical across algorithms. The cases where it matters are large refactors where Myers can produce mis-aligned hunks (a brace from one function gets paired with a brace from the next) and code with many repeated tokens. A 2019 Springer empirical study on Git diff algorithms found Histogram produced "better" diffs in 40.3% of files and Myers in 10.9%, with the rest a tie — meaningful but not dramatic. If a diff looks visually wrong, regenerate with Histogram or Patience and compare.