Compare two versions by line, word or character, side by side or inline, and export the patch.
Comparing two versions of a text is a common need in editing, code, contracts, documentation and content work. A diff splits both texts into lines and classifies each one as same, added, removed or changed, instead of rereading everything, you look only at what changed. Under the hood, this tool uses the Myers algorithm, the same method behind the diff command and Git, which searches for the smallest set of insertions and deletions that turns one text into the other. When the texts are too large for that exact computation, the comparison is anchored on lines that appear exactly once on both sides and the rest is resolved around those anchors, a technique known as patience diff. Nothing is discarded along the way: if some stretch has to fall back to block mode, the tool says so instead of quietly hiding content. Beyond the line diff, you can highlight exactly the word or character that changed inside a modified line, switch between the side-by-side and the inline view, ignore whitespace, letter case, blank lines and line-ending differences, follow the similarity percentage and export the result as a unified patch or an HTML report. All of it happens in your browser.
A line diff does not compare character by character blindly: it first finds the longest run of lines the two texts have in common, in the same order. Those lines become anchors marked as same. Everything left between one anchor and the next is read as removed lines (present in the original and gone) or added lines (appearing only in the modified text).
When a removal and an addition land in the same stretch, they are paired and counted as a changed line, which is the most common kind of edit. That pair is where the inline highlight kicks in: in word mode, only the replaced term is marked inside the line; in character mode, the highlight goes down to the letter or digit. Line mode turns the inline highlight off and shows the change as a pair of whole lines.
The four comparison options change what counts as a difference, not what is shown on screen: the displayed text is always what you pasted. Ignoring whitespace trims the start and end of each line and treats runs of spaces as a single space, useful when reindenting a file or pasting a document filled the text with new spaces. Ignoring letter case settles comparisons of lists, names and titles that were capitalized differently.
Ignoring blank lines removes empty lines from both sides before comparing, which prevents one extra paragraph break from shifting the whole document and producing a huge diff for nothing. Treating CRLF and LF as equal settles the classic friction between files saved on Windows and on Linux or macOS, where two identical texts would show up as completely different because of an invisible line-ending character. One honest caveat: with any of these options on, the exported patch describes the normalized comparison, so it is meant for review and will not necessarily apply without adjustment.
Suppose a report where the line 'The team closed 120 contracts in March' becomes 'The team closed 138 contracts in March', the region list gains one more entry and the closing line now names two people instead of one. In line detail you see three pairs of changed lines. In word detail, the highlight points exactly at '120' against '138', the added region and the new name, which is what a reviewer actually needs to see.
The counters separate additions, removals and changed lines precisely because a line edit counts as one removal plus one addition. The similarity percentage gives the opposite and complementary reading: how much of the content stayed identical. A report with three touched lines keeps a high similarity, while a full rewrite drops the number even when the line count looks similar.
Comparing texts with a diff is used for editorial review, contract checking, documentation change analysis, code review, translation checking and any workflow where changes must be identified clearly. Two honest limits: a diff shows what changed, not which version is correct, and deciding what is right or approved depends on context and human review. And a patch, even in unified format, does not replace the history, authorship, branches and traceability of a version-control system like Git.
On performance and limits: the comparison always runs over the whole input, with no silent truncation. Long documents are rendered progressively, with the exact count of lines not shown yet and a button to reveal the rest, and file loading has a size ceiling that is stated on screen when you hit it. On privacy: the comparison, the reading of dropped files and the generation of the patch and the HTML report all happen in your browser. Neither text is sent to a server, so it is safe to compare contract drafts, proprietary code or sensitive documents.
Paste the code into your HTML and the tool shows up on your page, without J-Kit's navigation and ads. It still runs in the browser of whoever visits your site.
<iframe
src="https://jkit.tools/embed/en-US/text-diff"
width="100%"
height="600"
style="border:0"
loading="lazy"
title="Text Diff"
></iframe>These references help contextualize formulas, standards, APIs and limitations used on this page. They do not replace professional validation when a result has legal, financial, medical or operational impact.
Yes, and it goes further. The base comparison is by line, but inside each changed line you can ask for word-level or character-level highlighting, which shows exactly the term that changed instead of marking the whole line.
Comparison, file reading and export all run in your browser. No content is sent to a server.