Text Diff Checker

Paste or load the starting version under Original and the other under Changed. The line-numbered side-by-side result appears automatically and counts modified, added and removed lines. Choose Character, Word or Line to open an inline highlight at that detail, or use Previous and Next to move through the side-by-side change groups.

Either works for plain-text files. Use Load original file and Load changed file for text, Markdown, CSV, JSON, XML, source code, configuration or log files up to 5 MB each, or paste directly into the boxes. The browser reads the file locally. Rich formats such as .docx and PDF are not text files, so extract or copy their text first.

Red belongs to Original and means removed or replaced; green belongs to Changed and means added or replacement text. The side-by-side view colours the affected line, while Unified marks the exact character, word or line. The colours show direction rather than right and wrong, so swapping the two inputs swaps red and green.

Yes. Side by side is the default result: both versions share one scroll area, carry their own line numbers, and keep corresponding rows aligned. Modified lines sit opposite each other; a missing side is blank for a pure addition or removal. Unified remains available when a single inline reading flow is easier.

Neither is more correct; they show the same edit at different detail. Character isolates a letter or punctuation mark, Word is easiest to scan in prose, and Line matches code reviews, configuration and logs. Side-by-side counts are always line-based, while those three controls set the Unified highlight detail.

Start with Side by side and Line detail because the numbered rows match the language of a pull request. Keep whitespace visible for YAML, Python and makefiles. If a modified line is not obvious, choose Character or Word to open Unified and isolate the identifier, number or punctuation that changed.

Word detail is usually clearest because it points to an altered figure, name or clause without treating wrapping as the edit. Character detail is useful for punctuation and spelling. Ignore whitespace or case only when those differences genuinely do not matter; capitalisation can change the meaning of a defined contract term.

Look for a straight versus curly quote, hyphen versus dash, non-breaking space, extra indentation or different line ending. Toggle whitespace, letter case or CRLF-versus-LF to test whether the difference is only formatting noise. Character detail is the best way to expose a remaining invisible or one-character edit.

The files may use different line separators. Windows commonly writes CRLF while macOS and Linux use LF; old Mac text can use CR. CRLF versus LF is ignored by default here, so turn that control off only if the byte-level line ending itself is what you need to audit.

Word detail deliberately treats a word as the useful unit. Choose Character and the Unified view will isolate the exact letter — for example, colour versus color marks only the u. Side by side continues to colour the containing line because its job is alignment and navigation.

No, and this is the limitation most likely to catch you out. Neither mode has any notion of a move. Take a paragraph from the middle of a document and put it at the top and it appears green where it now sits and red where it used to, the same text coloured twice, with nothing to say they are the same text. On a reordered config file that makes a small edit look enormous. If you only need to know whether anything was lost in the reshuffle, sort both versions the same way before pasting.

The status says the texts match with the selected options, the side-by-side rows remain plain, and the change buttons disable. Remember that a match can be conditional: if Ignore case or Ignore whitespace is on, the exact source may still differ. The downloaded patch preserves those exact differences.

Every line on the populated side is marked because, compared with nothing, it is all added or all removed. The side-by-side view leaves the other column blank; Unified colours the text in one direction. This is valid, but a result entirely in one colour often means the second paste or file selection did not happen.

Each loaded file can be up to 5 MB, each side can contain up to 50,000 lines, and the pair can contain up to 10 million characters. Character detail falls back to Line above 50,000 combined characters and Word above 100,000. A heavily different pair can be harder than a longer similar pair, so the comparison also stops safely if its time or edit-distance guard is reached and asks for smaller sections.

Each side is capped at 50,000 physical lines. The side-by-side result gives both versions their original line numbers and Previous and Next buttons jump through adjacent change groups. To protect the page from tens of thousands of DOM rows, it displays a 5,000-row window around the selected change while counts and a successful export still cover the whole comparison.

No. The comparison happens in the page: the diff library is part of the JavaScript already downloaded, the component makes no network request of any kind, and there is no server route behind it. Nothing is kept either — both boxes are ordinary component state, so closing the tab is the whole of the cleanup. That matters more here than on most text tools, because a diff is by definition two copies of something important enough to have a before and an after: a settlement letter against the version your solicitor returned, or two exports of a customer list.

It does not. Both boxes are ordinary page state and nothing is written to your browser storage, so a reload returns two empty boxes rather than your last comparison. There is no list of recent runs, no account to attach one to, and no way to reopen something from yesterday. If a comparison matters, keep the two versions themselves — they are the thing worth saving, and the result takes seconds to produce again.

No. Nothing you paste is put into the address bar, so this page URL is the same one everybody else has and sending it hands over the empty tool rather than your text. That is a deliberate trade: text placed in a URL travels into browser history, into whatever chat window the link is pasted into, and into the logs of every server in between. To show a colleague what changed, send the two versions and let them paste.

Yes. Copy diff puts a valid unified patch on the clipboard and Download .diff saves the same kind of patch. It includes file headers, hunk ranges and normally three context lines, so distant unchanged text is left out. The export records exact text even when an Ignore control hides a difference in the visual result.

Its plain text will, once you copy and paste it, but .docx is a ZIP-based document format and is not accepted by the text-file picker. Formatting-only changes — comments, font, highlighting, heading style or table borders — have no plain-text difference and cannot appear. Export each document to .txt first if you want to use file loading.

Same route, with one thing to check first. Copy the text out of each and paste it in; the comparison then behaves normally. A PDF produced by a scanner or a phone camera holds a picture of a page and no text at all, so there is nothing to select — that needs character recognition first. And text copied from a PDF arrives with the line breaks the layout happened to have rather than the ones the sentences want, so use Word-level, which does not care where lines fall.

Yes, and it is one of the quicker uses for this. Copy one column into Original, the other into Changed, and choose Line-level: a spreadsheet copies one cell per line, so each row becomes a line and the two sides align naturally. You get which entries differ, in order. What you do not get is any awareness of a row that simply moved, so sort both columns the same way first — otherwise a reordered list comes back looking as though every row changed.

Yes. Tick Letter case under Ignore and "The Client" matches "the client" in both views. Leave it off for code, environment variables and defined contract terms, where capitalisation can change meaning. The downloaded patch remains exact and therefore still records the case change.

Yes. Ignore Whitespace trims horizontal spaces and tabs, collapses runs, and drops whitespace-only lines before comparing. It does not silently decide that a missing final newline is the same thing; line-ending type has its own control. Keep whitespace visible for YAML, Python, makefiles and any format where indentation carries meaning.

No — two boxes is the whole tool. A three-way comparison is a different job, the one a version-control system does when it reconciles two sets of edits against a common ancestor, and it needs a different interface to display. The practical approach here is pairs: original against first revision, then first revision against second. Two passes tell you what changed at each step, which is usually the question underneath anyway.

Track changes records edits as they are made, so it knows who typed what and when, and each mark can be accepted or rejected individually. This works the other way round: it is handed two finished texts and works out what must have happened between them. That is exactly what you need when track changes was never switched on, or when the copy you were sent had every mark accepted before it reached you. The trade is that it shows a difference but cannot apply or undo one.

A git diff compares committed versions of files inside a repository, reports in whole lines, and carries the context a repository holds: who changed it, when, against which commit. This has no repository and no memory. It compares two blocks of text you paste, which is the point — the two things you want to check are often not in version control at all, or sit on different machines, or are an email and a document. Line-level gives the same granularity without either version being committed anywhere.

Yes. The inputs stack on a narrow screen. The line-numbered result keeps its two-column alignment and scrolls horizontally inside its own panel, while Unified is easier for reading prose on a phone. Nothing is stored, so load both local text files or keep both versions ready before navigating away from the page.

Once you have opened the page while connected, yes. The site stores this page and the files it depends on, so reopening it with the network off gives a working tool rather than an error. That turns the claim about local processing into something you can test rather than something you have to believe: a tool still comparing text with the connection pulled cannot be sending it anywhere. Only the first visit needs a connection.

It is free with no account or sign-in. Character, word and line detail, both result views, file loading, ignore controls, navigation, copy and download are all available on the page. Device-safety limits are shown plainly: 5 MB per loaded file, 50,000 lines per side and 10 million characters combined.

Yes, on anything your browser can display. Accented letters are treated as part of the words they belong to, so "café" against "cafe" marks that word. Scripts written without spaces between words behave differently but well: a Chinese sentence is compared character by character, so altering one two-character word marks those two characters and leaves the rest plain, which is tighter than word granularity would manage. Japanese behaves the same way. Thai does not: it has no spaces either, but the comparison cuts inside words rather than between them, so a changed word comes back as two fragments and a stray letter.

Yes, and format both the same way. This compares text and knows nothing about structure, so a minified document against a pretty-printed one is reported as one enormous change even when every value matches. Run both through a JSON formatter first, then compare at Line-level, since each key then sits on its own line. One thing survives the tidying: reordering keys changes nothing about the data and everything about the text, so a reordered document is still marked as changed throughout.

Not in the sense the word usually means. It compares two texts you supply and nothing else — it does not search the web, has no library of documents behind it, and cannot tell you where a passage came from. What it can settle is a suspicion you already have: paste the passage in question and the source you think it came from, and the uncoloured stretches are the parts that match word for word. That answers how much is the same, not where it came from.

Because Original is the starting point and Changed is measured against it. Swap sides trades every removal for an addition and therefore every red direction for green. The set of edits is the same, but its direction is reversed. Use the Swap sides button if the versions went into the wrong boxes.