Compare two texts or files with word-level highlights, line numbers, whitespace rules and a copy-ready unified patch. Runs entirely in your browser.
Line alignment first, then the comparison unit for what changed inside a line.
--- a/original.txt+++ b/changed.txt@@ -1,8 +1,8 @@ # deploy.yaml service: checkout-replicas: 2-image: acme/checkout:1.4.2-memory: 512Mi+replicas: 4+image: acme/checkout:1.5.0+memory: 1Gi healthcheck: /healthz region: us-east-1-timeout: 30+timeout: 45
The patch mirrors the options you selected, so a comparison that ignores whitespace or case describes that difference rather than a byte-for-byte one.
Every row carries a sign and a tint: a blank sign for unchanged, a rose minus for a line only in the original, an emerald plus for a line only in the changed side. When a line exists on one side only, the other half is drawn as an empty cell so the two columns stay aligned.
The unified view is the patch, in patch order: every removal of a region, then every addition, with three unchanged lines kept around each hunk. The exported file carries ---, +++ and @@ headers, and the project's test suite applies a generated patch with git apply before every deploy.
The engine stops and says so past an edit distance of 4,000 instead of returning a coarser alignment, and skips word-level marking above 4,000 characters in a single line. Uploads are capped at 2 MB per side. Nothing is silently dropped: a stopped comparison tells you which limit it hit.
Compare two JSON payloads structurally instead of textually: added, removed and modified keys reported with their exact path, key order ignored or enforced, and a formatter that points at the line and column where a payload stopped being JSON.
Open toolClean both sides first — case, trailing spaces, blank lines, accents, smart quotes and punctuation — then read a similarity score built from Levenshtein distance and Jaccard overlap, and see exactly what still differs.
Open toolAn illustrated walk through Myers' greedy algorithm on this same engine: how the edit graph is built, why the shortest edit script is the readable one, and when a diff has to stop early and say so. In development on the same client-side code.
In developmentViews, highlights, folding and line endings.
Split shows the two documents in parallel, which is what a review needs: every row carries both line numbers and the filler half of a one-sided change is drawn as an empty cell. Unified shows the patch order — all removals of a region, then all additions — which is what a terminal or a code review prints, and what the copy button exports.
Lines are aligned first, then the changed words inside a changed line are marked: removed words in rose on the left, added words in emerald on the right. Aligning by word first would make a re-wrapped paragraph read as if everything changed, which is the failure mode this order avoids.
So a small edit in a large file stays on screen. Two lines of context are kept at each end of the run and the fold states how many lines it hides; clicking it expands them in place. The fold count is exact, not a rounded value.
Yes. LF, CRLF and a lone CR are all treated as line breaks, so a file saved on Windows and the same file saved on Linux compare as equal rather than as every line changed.