How to Redline a Contract (2026)

What Redlining Actually Means

A redline is a visual comparison between two versions of the same document showing exactly what changed — what was deleted (typically struck through in red), what was added (typically underlined or shown in a different color), and what stayed the same. The practice originated with literal red pens on paper contracts, where lawyers would cross out objectionable text and write proposed replacements in the margins. The digital version preserves that metaphor, just automated.

Redlining is different from 'tracking changes' in an editing sense. Track Changes records edits as they happen — you have to turn it on before you start editing, and it has to stay on the whole time. Redlining happens after the fact by comparing two final artifacts. You can redline any two versions even if neither was edited with tracking enabled. This matters because contracts travel — they get sent as PDFs, printed and scanned, converted between formats, routed through signing platforms that flatten everything. Track Changes gets lost; redlining works on whatever artifact you have.

The output of a redline isn't usually the final document — it's a review document. Lawyers and reviewers read through the redline to understand what changed, approve or reject specific edits in conversation with the counterparty, then agree on a clean version that becomes the executed contract. So the redline is a diagnostic tool, not a delivery artifact.

When Redlining Matters

Any time you receive a contract back from a counterparty that's supposedly 'just a small update.' Unless you have complete trust in the other side, you need to know exactly what they changed. A 'small update' that replaces a 'reasonable efforts' standard with a 'best efforts' standard, or quietly removes a limitation-of-liability cap, or inserts a venue clause in a favorable jurisdiction — these matter, and they're often buried on page 17.

Before signing. Every final contract should be compared against the last version you explicitly approved. If the executed version differs — even by a word — you need to know before you sign. The horror stories of signed contracts that contained terms one party never agreed to usually trace back to a missed redline step.

Negotiation volleyball. In back-and-forth negotiation, every exchange produces a new redline. V1 → V2 (your markup) → V3 (their markup of your markup) → V4, and so on. Each handoff, the receiver should redline the incoming version against what they sent, to isolate exactly what the other side touched.

Template drift audits. If your company maintains contract templates, redline new template versions against the last approved one whenever someone updates them. Template drift — small changes accumulating over versions without review — is how compliance clauses get lost, indemnity caps get forgotten, and companies end up with execution-ready templates that don't actually reflect their current policies.

The Professional Redline Workflow

Step 1 — Identify the two versions. You need a clear 'original' (what you agreed to last) and a 'revised' (what you're reviewing now). Label them clearly in filenames. Don't redline against something ambiguous like 'latest draft' — tie the comparison to a specific dated version.

Step 2 — Extract text from both. PDFs and Word documents both contain text that a comparison tool can read — our Contract Redline tool does this automatically using pdf.js and mammoth. If your PDF is a scan without a text layer, run it through OCR first. Our PDF OCR tool adds a searchable text layer in-browser; then feed the OCR'd result into the redline tool.

Step 3 — Generate the redline. Drop both files into a comparison tool; in ours, click 'Generate Redline.' The output shows insertions in green, deletions struck through in red, and unchanged text in normal color. Toggle between word-level (finer grain, better for subtle wording changes) and line-level (coarser, better for seeing structural changes) depending on what you're investigating.

Step 4 — Review systematically. Read the redline top to bottom. Flag any insertions that expand the counterparty's rights or reduce yours. Flag any deletions that remove protections you relied on. Flag any substitutions where a subjective standard ('reasonable,' 'best efforts,' 'material') got swapped for a different one. Don't assume 'small changes' are innocuous — small wording changes are usually where the real negotiation happens.

Step 5 — Produce a response. Your output isn't the redline itself — it's the conversation you have with the counterparty about which changes you accept, reject, or want to counter. Walk through each flagged item in your response. Keep the redline handy as the source document both sides reference during that conversation.

What Other Tools Cost

Microsoft Word's Compare feature (Review → Compare) is the closest thing to a built-in free redline tool. It works well if both files are Word documents and the formatting hasn't drifted much. The caveats: it struggles with PDFs (you'd have to convert first), it's clunky for non-Word users, and the output is a Word document that's hard to share without everyone having Word.

Adobe Acrobat Pro has a Compare Files feature at about $239.88/year. It handles PDF-to-PDF comparison competently and produces a side-by-side visual diff. For Word-to-Word or mixed-format comparisons, it converts first, which can introduce formatting artifacts. It's built into the broader Acrobat subscription — if you already pay for Acrobat Pro, use it.

Enterprise contract platforms (Ironclad, LinkSquares, ContractPodAi, DocuSign CLM) include redlining in their $100-500-per-user-per-month subscriptions. They add workflow features around redlining — routing, approvals, playbooks — that are useful for legal teams at scale but overkill for individuals or small teams.

Free online options exist but are mostly signup-gated. Draftable's free tier has limits; Ipri.io requires account creation; most 'free' compare tools upload your document to their servers. For sensitive commercial contracts, uploading the text of a deal to an unknown third party is a security problem most corporate legal teams won't accept.

Our tool does the comparison step entirely in-browser — nothing uploads, nothing logs. That's the tradeoff: you don't get the workflow features (routing, approval, playbooks), but you get the core redline capability with strong privacy properties, for free, in any browser.

Limitations of Any Text-Based Redline

Text-based redlining compares the text of the two documents and doesn't see formatting changes. If one version changes every instance of bold to italic, or renumbers sections 1–20 to 1.1–1.20, or reorganizes layout, text-based comparison will see them as mostly unchanged (the words are still there). This is usually fine for contract review since the legal substance is in the words — but if formatting matters (e.g., because the contract specifies particular formatting), use a visual comparison tool as well.

Moved paragraphs show as a deletion in one place and an insertion in another. The diff algorithm doesn't know that paragraph X moved from section 3 to section 7; it only sees 'this text isn't here anymore' and 'new text appeared here.' In practice this is OK — reading the redline with the surrounding context usually makes moves obvious — but if you have many reorderings, consider reading both documents side-by-side in addition to the redline.

OCR errors create false differences. If your 'original' was scanned and OCR'd, and your 'revised' is a clean digital document, the OCR output probably has small character errors (l vs I, rn vs m, 0 vs O) that the diff will flag as changes. This is a data quality problem, not a redline problem — clean OCR input before comparing, or accept that OCR'd comparisons will have false-positive noise.

Signature blocks and date stamps often differ between versions even when the contract body hasn't changed. Review the redline with this in mind — a deletion at the end of the document showing an old signature date replaced with a new one isn't a substantive change, it's just an expected artifact of signing.