What this text diff actually compares
The workbench treats each input as an ordered sequence of lines. It finds a shortest sequence of line insertions and deletions that turns the original sequence into the modified sequence. An apparent “changed line” is therefore represented internally as a deletion next to an addition. The side-by-side view pairs nearby deleted and added lines for review, then performs a smaller token comparison to emphasize the words, punctuation or spaces that changed inside the pair.
That model is useful for source code, JSON snapshots, environment-variable templates, server configuration, generated output and edited prose. It does not understand syntax, variable renames, moved functions or meaning. Two semantically equivalent programs may look very different, while a one-character security change may look small.
Why the algorithm is bounded
The line engine uses the Myers shortest-edit approach, the classic algorithm described in Eugene Myers’ 1986 paper. Git’s current documentation still identifies Myers as its basic default diff family while also offering minimal, patience and histogram alternatives. Different algorithms can choose different—but valid—alignments when lines repeat. This tool does not claim byte-for-byte parity with a particular Git or GNU Diffutils version.
Interactive browser tools need explicit resource limits. Each side is capped at 10,000 lines and two million characters. The engine also stops when the shortest path would require more than 2,500 insertions plus deletions. A large file with a small change can fit easily; two completely unrelated large files can hit the edit-distance limit. Stopping is safer than allocating a quadratic matrix or freezing the tab.
Side-by-side view versus unified diff
The side-by-side view is optimized for reading. It preserves original line numbers, pairs nearby removed and added lines, and highlights changed tokens for reasonably sized lines. Unchanged regions are folded according to the Context setting. Choose “All lines” when you need the complete document, but expect more browser work on long inputs.
The unified view follows the familiar structure documented by GNU Diffutils: an original label, a modified label and one or more hunks beginning with @@. Lines beginning with a space are context, - marks removal and + marks addition. Three context lines is the conventional default and is generally safer for human review and patch matching than zero context.
What the ignore options mean
- Ignore case compares lowercased line values. It can hide changes that matter in passwords, identifiers, paths, environment variables and case-sensitive filesystems.
- Ignore all whitespace removes Unicode whitespace before line matching. It can be helpful for reformatting noise, but it also treats
"a b"and"ab"as equal at the line level. - Ignore blank lines removes blank lines from the compared sequence while retaining the original line numbers of remaining content. The resulting unified output is for review and may not be safely applicable as a patch.
The “line overlap” statistic is the unchanged-line count divided by the larger compared line count. It is a transparent navigation aid, not semantic similarity, plagiarism detection or a quality score. A high percentage can coexist with a critical one-line change.
A reliable comparison workflow
- Normalize the source intentionally. Format JSON with the JSON Formatter if structure—not original spacing—is what matters. Keep raw input when whitespace or ordering is evidence.
- Start without ignore options. Review the exact change first. Enable one ignore option at a time only when the suppressed difference is known to be irrelevant.
- Inspect change blocks, not just counts. An addition and deletion may be a replacement, a move or two unrelated edits. The pairing in a visual table is a presentation heuristic.
- Export for review. Give the labels meaningful filenames, copy or download the unified output, and verify it before applying with Git or
patch. - Validate the result in its own domain. Parse JSON, run tests, lint configuration, compile code or inspect rendered documents. Text equality cannot prove operational correctness.
Privacy and sensitive inputs
Comparison code runs in this browser. EasyTool does not upload or store the two text areas. Clearing or closing the page removes the in-page state unless the browser restores form contents. Copying sends output to the system clipboard, and downloading creates a local file; either can later be read or shared outside this page.
A browser-local tool is not automatically appropriate for every secret. Managed devices, browser extensions, clipboard managers, screen recording, crash reporting and other software can observe content. Redact production credentials, tokens, personal data and customer logs when the comparison does not require them.
Text and patch limitations
HTML text areas may normalize line endings, so this page is not a CRLF-versus-LF detector or a binary-file comparator. It does not preserve file permissions, timestamps, rename metadata, encodings outside browser text, Git index lines or “no newline at end of file” markers. The exported unified text is designed for review and common patch-shaped workflows, but it is not guaranteed to apply to a file that differs from the pasted original.
For repository changes, use git diff against the actual working tree. For directories, binary files, enormous changes, rename detection or a patch that must be applied automatically, use Git, GNU Diffutils or another file-aware tool. This browser tool is strongest when you need a fast, private comparison of two bounded text snapshots.
Primary references
- GNU Diffutils manual: comparison, side-by-side and unified formats
- Git documentation: Myers, minimal, patience and histogram algorithms
- Eugene W. Myers, “An O(ND) Difference Algorithm and Its Variations”
Implementation and editorial review: 2026-08-02. Algorithm and output behavior are covered by deterministic examples plus randomized shortest-edit property tests in the site build.