Document Review & Contracts
A counterparty returns a contract with their changes. A policy comes back revised after legal review. You receive a document you've seen before and need to know: what's different? The answer matters more than it sounds — a single changed clause in a contract can shift liability, alter payment terms, or create an exit right that wasn't there before. This guide covers the main methods for comparing document versions, what each one is good for, and how to choose the right one for the situation.
Documents go through multiple versions for reasons ranging from negotiation to regulatory updates to clerical errors. The problem with received revisions is that the changes aren't always disclosed — a counterparty's tracked changes may be accepted before sharing, a policy may arrive as a clean document with no indication of what moved, or a contract may be re-sent with changes the sender hopes go unnoticed.
In active contract negotiations, counterparties sometimes return a document with changes they hope will be adopted without scrutiny — particularly in long agreements where reading every clause again is impractical. Standard practice requires counterparties to use tracked changes; not all do. Without a systematic comparison, a changed indemnification clause, an added limitation-of-liability cap, or a modified payment term can be missed.
Organizations that issue periodic policy updates — employee handbooks, vendor terms, privacy policies, or operating procedures — often distribute the new version without a change summary. For the recipient, the question is: what specifically changed, and does it affect me? Reading two policies side-by-side works for short documents; for longer ones, systematic comparison is faster and more reliable.
Regulated industries receive updated forms, disclosure templates, and compliance documents from regulators, associations, or insurers. Understanding exactly what changed — whether a new disclosure was added, a liability statement was modified, or a defined term was altered — is a compliance obligation. Manual comparison at scale is error-prone; systematic comparison catches the specific changes.
After a contract has been agreed in principle, the final version for signature should match the last agreed draft. Clerical errors, inadvertent version rollbacks, or deliberate last-minute changes occasionally appear in the final version. Checking the signature version against the last approved draft before signing is a standard risk control.
For short documents or when the changes are expected to be limited, reading the two versions side by side remains a valid approach — but it has known failure modes.
The oldest method: open both documents, either side-by-side on screen or printed, and read them in parallel. This works reliably only for short documents (a few pages) where the reader can hold the context of both versions simultaneously. For documents longer than 5–10 pages, manual side-by-side reading reliably misses changes — particularly single-word substitutions, moved paragraphs, and changed numbers.
If the counterparty has disclosed which sections they revised, reading only those sections is efficient — but it trusts the counterparty's disclosure to be complete. This is a reasonable approach in well-established relationships with transparent counterparties; for adversarial or unfamiliar counterparties, it's a vulnerability.
Printing both versions and using colored highlighters to mark differences is more systematic than reading alone — but it remains prone to missed changes, particularly in long dense paragraphs where single-word changes are easy to overlook. It also produces a non-digital artifact that's hard to share or audit.
In Word, Google Docs, and similar word processors, tracked changes (or 'suggesting mode') records each edit as an annotation, attributing it to a user and making additions/deletions visible without hiding the original. This is the standard mechanism for document negotiation in most professional contexts.
Tracked changes marks additions (typically underlined or in green) and deletions (strikethrough, often in red) so both versions of a changed passage are visible simultaneously. Comments are also visible. The reviewer can accept or reject each change individually. This is the clearest format for reviewing revisions — when the counterparty has used it.
Tracked changes requires both parties to work in the same editable format (Word/DOCX, Google Docs). When a document arrives as a PDF — as many executed contracts, regulatory filings, and formally distributed documents do — there's no tracked-changes layer. PDFs don't natively record revision history. Comparison then requires either converting to an editable format (with risk of formatting changes) or using a PDF-specific comparison tool.
Before sharing a revised document, some counterparties accept all their tracked changes — converting the revision marks to clean text — so the document appears as a fresh unedited version. This is standard when producing a 'clean' copy of an agreed document but problematic when done to obscure changes that haven't been agreed. Receiving a document with tracked changes accepted means you're looking at a clean version with no revision record, making comparison essential.
PDF redlining tools compare two PDF files by extracting their text content, computing a diff, and highlighting additions and deletions in the output — often color-coded (additions in green, deletions in red) in the same visual format as tracked changes.
The tool extracts the text from each PDF, aligns it at the paragraph or sentence level, and runs a diff algorithm (similar to the `diff` utilities used for code) to identify additions, deletions, and unchanged passages. The result is presented as an annotated document showing what changed between version A and version B. Formatting changes (font size, margins, spacing) are typically not captured — only text-level changes.
Added or deleted text at any scale — a single word ('not' added before 'liable'), a changed number ('30 days' to '90 days'), a new paragraph, or an entire added section. It catches changes regardless of where in the document they appear, without requiring the reviewer to read every word of both versions.
PDF redlining works on text content. It does not detect formatting changes (a table restructured to hide information, font size reduced to make a clause less prominent), image substitutions, or changes in embedded attachments. For high-stakes agreements, PDF comparison supplements but does not replace careful legal review — it tells you where the text changed, not what the changed text means legally.
PDFs created by scanning physical documents don't contain machine-readable text — they contain images of text. PDF comparison tools work on extracted text; a scanned PDF without an OCR layer provides no text to compare. If your PDFs are scanned, use OCR software to add a text layer before comparing. Some PDF comparison tools include built-in OCR.
The right comparison method depends on the document type, format, stakes, and how the document arrived.
Use tracked changes. Ask the counterparty to share revisions with track changes on, or turn it on yourself and compare manually. If they've sent a clean version, use a Word comparison tool (Word → Review → Compare → Compare Documents, or Google Docs → File → Version history if you uploaded both versions).
Use a PDF redlining tool. This is the cleanest approach when you have two PDF versions and want a systematic text comparison. A local browser-based redline tool (which doesn't upload your document to a server) is appropriate for confidential documents.
Manual review of the specified sections, followed by a quick skim of the rest for anything unexpected. This is reasonable for trusted counterparties and short documents. Consider a tool comparison as a verification step if the stakes are high.
Use automated comparison regardless of document length, then review the flagged changes. Don't rely solely on manual reading for high-stakes agreements. After the automated comparison, consider having counsel review the changed sections specifically.
For documents containing personal data, trade secrets, privileged communications, or information subject to data residency requirements, use a comparison tool that doesn't upload the document to an external server. Browser-based local tools process both PDFs in browser memory, with no server transmission, and are verifiable via DevTools.
Use a PDF comparison (redlining) tool that accepts two PDF files and outputs a diff highlighting additions and deletions. Browser-based PDF redlining tools extract text from both PDFs, compute a text diff, and present the results with additions highlighted (typically green) and deletions shown in strikethrough (typically red), in the same visual format as Word tracked changes. For confidential documents, use a tool that processes both PDFs locally in your browser without uploading them to a server — you can verify this with the DevTools Network tab.
Tracked changes is a feature of editable word processors (Word, Google Docs) that records each edit as it's made, attributing it to a user. Redlining refers to comparing two finished documents — often PDFs — and marking what changed between them. Tracked changes is built into the document's editing workflow; redlining is a retrospective comparison of two versions. For PDFs, which don't have a native edit-tracking layer, redlining tools compute the diff from the extracted text of both files.
Yes. Browser-based PDF comparison tools extract the text from both PDFs within your browser's JavaScript environment, compute the diff locally, and display the result — without sending either document to a server. Open DevTools (F12) → Network tab before loading your PDFs, then run the comparison. A local tool shows no outbound requests carrying your document content. This is the appropriate approach for contracts, legal documents, or any document containing information you'd rather not transmit to a third-party server.
PDF text comparison detects text additions, deletions, and substitutions. It does not detect formatting changes (a clause moved to smaller font, a table restructured to de-emphasize a term), image substitutions, changes in embedded attachments, or metadata changes. For most practical document comparison purposes, text-level changes are what matter — but for high-stakes agreements, supplement automated comparison with careful human review of the changed sections.
Only if they have a machine-readable text layer. PDFs created by scanning physical documents contain images of text, not selectable text. PDF comparison tools work on the text content — they need machine-readable text to extract. If your PDFs are scanned without OCR, you'll need to run OCR first to add a text layer before comparison. You can check whether a PDF has selectable text by trying to click and drag to select text in a PDF viewer — if it selects, the PDF has a text layer.
Run a PDF redline comparison between your last approved draft and the final version sent for signature. Any differences will appear as additions (green) or deletions (red). Pay particular attention to: defined terms (a changed definition in Section 1 can alter the meaning of every clause that uses that term); liability and indemnification sections; payment terms and amounts; and notice and termination clauses. If differences appear that weren't discussed or agreed, raise them before signing — not after.