About the Document Diff
Word documents and PDFs are the formats contracts, specifications, and policies travel in, and neither one lets you see what changed between two versions unless the sender remembered to enable track changes. Usually they did not.
This tool extracts the text from both documents in your browser and diffs it line by line, so you can see what was added, removed, and reworded without needing Word, Acrobat, or an upload to a comparison service.
When you'd use it
- Finding what a counterparty changed in a redlined contract before you sign it.
- Comparing two revisions of a specification or requirements document.
- Checking a translated or reformatted document against the original text.
- Verifying that a document export preserved the content it was supposed to.
- Reviewing edits in a policy document circulated by email.
What "extract the text" means, and what it loses
A .docx file is a zip archive containing XML. Extraction walks that XML and pulls out the paragraph text in document order, which is reliable because the structure is explicit.
What extraction deliberately drops is presentation: fonts, colours, sizes, and styles. A paragraph restyled from body text to a heading, with no wording change, will not appear in the diff. If you need to review formatting changes, this is the wrong tool — but for the far more common question of what the document now says, dropping formatting is what makes the diff readable.
PDFs are harder, and here is why
A PDF does not store paragraphs. It stores instructions to draw glyphs at coordinates. Reconstructing reading order from that is inference, and it is usually right for a single-column document and frequently wrong for multi-column layouts, tables, sidebars, and anything with text in headers or footers.
The practical consequences: text from a two-column page may interleave, table cells may run together, and a hyphenated word broken across a line may extract with the hyphen intact. If a PDF diff looks scrambled, the layout is why, and comparing the source .docx files instead will give a far cleaner result.
Scanned documents
A PDF produced by a scanner contains images of pages, not text. There is no text layer to extract, so the tool will report an empty or near-empty document. This is not a failure of the comparison — there genuinely is no text in the file. Running the PDF through OCR first is the only path, and the accuracy of the diff will then depend on the accuracy of the OCR.
Reading a document diff
Prose diffs differently from code. Reflowing a paragraph — changing one word near the start — can push every subsequent word onto a different line, so a line-oriented diff may report the whole paragraph as changed for a single-word edit.
Read the highlighted region rather than the line count, and treat a large block of changes in continuous prose as a prompt to look at the wording rather than as evidence of a large rewrite.
Frequently asked questions
- Which formats are supported?
- .docx for Word documents and .pdf for PDFs. The older binary .doc format is not supported — open it in Word or LibreOffice and save as .docx first.
- Are my documents uploaded?
- No. Both are parsed in your browser. Given that this tool exists mainly for contracts and internal specifications, that is the entire point.
- Will it show formatting changes?
- No. The comparison is on extracted text. Font, colour, and style changes are invisible to it.
- Can I compare a .docx against a .pdf?
- Yes — both are reduced to text, so cross-format comparison works. Expect noise from the PDF side, since its extraction is inferred rather than read directly.
- The PDF came out as gibberish or empty. Why?
- Either it is a scan with no text layer, or it embeds fonts with a non-standard character mapping, which makes extracted characters map to the wrong glyphs. Selecting and copying text in a PDF reader is a quick test: if you cannot copy readable text there, extraction cannot recover it either.