It is 4:40pm and the counterparty just sent back the MSA with 63 tracked changes, 14 comments, and a renumbered Section 9.3 that quietly broke three cross-references. That is redlining, and this is how to handle it.
It is 4:40pm on a Thursday and the counterparty's counsel has just emailed back the Master Services Agreement. The file is called MSA_v4_JJ_comments_CLEAN_v2.docx. You open it. There are 63 tracked changes, 14 comments, and someone has accepted a portion of your previous round without telling you which portion. Section 9.3 has been renumbered to 9.4, which means the three cross-references pointing at it are now pointing at the wrong clause. Nobody notices this for another nine days.
That is redlining. Not the clean concept described in a legal dictionary, but the actual, messy, high-stakes practice of marking up a contract so two parties can converge on language they will both be legally bound by.
If you are searching for what redlining means, you are probably in one of three situations. You just received a marked-up contract and need to know what to do with it. You have been asked to redline something and want to know the conventions. Or you are evaluating whether your team's redlining process is as bad as it feels. This guide covers all three.
Contract redlining is the process of proposing, tracking, and negotiating changes to a draft agreement so that every edit is visible and attributable. A redline shows what was added, what was deleted, and who proposed it.
The name is literal. Before word processors, lawyers marked up printed drafts with a red pen. Deletions were struck through in red. Insertions were written in the margin in red. The convention survived the move to software: in Microsoft Word, tracked changes render insertions as underlined colored text and deletions as strikethrough, with each author assigned a distinct color.
A few terms get used interchangeably and should not be:
Redline is the marked-up document itself, showing changes against a baseline version.
Blackline is a comparison document generated by diffing two versions. It is produced automatically rather than authored. In practice the two words are now used interchangeably in most US practice, though older practitioners distinguish them.
Clean version is the same document with all changes accepted and markup removed. It is what gets signed.
Markup is the broader category, covering both tracked edits and margin comments.
The distinction that actually matters day to day is between an authored redline (someone deliberately made these edits) and a generated blackline (software compared two files and found these differences). The second is the safety check on the first. If your counterparty sends a redline and you do not independently blackline it against your last sent version, you are trusting them to have disclosed every change they made. That trust is misplaced more often than most teams admit.
Contracts are negotiated documents. Neither party gets to dictate terms unilaterally, which means language moves back and forth until both sides can live with it. Redlining exists because that movement needs to be legible.
Three things depend on that legibility.
Consent has to be specific. When your general counsel approves a change to the limitation of liability clause, she is approving that specific language, not the contract generally. If the change is invisible, the approval is meaningless. Courts and auditors both care about who agreed to what and when.
Negotiation is iterative. A typical commercial agreement goes through three to six rounds. Each round needs to build on the last, not restart it. Without visible markup, round four cannot tell whether round three's concession was accepted or quietly reversed.
Institutional memory is thin. The lawyer who negotiated the original indemnity carve-out leaves. Two years later, someone asks why the carve-out exists. The redline history is the only record of the reasoning, assuming anyone preserved it.
Most people think of a redline as a list of word changes. In practice a competent redline carries four distinct layers, and confusing them causes most of the friction in negotiation.
Substantive edits change the legal effect. Moving a liability cap from 12 months of fees to 6 months. Adding a carve-out for gross negligence. Narrowing a license grant from perpetual to term-limited. These are the edits that need approval and that the other side will push back on.
Structural edits change how the document is organized. Splitting a clause into subsections, moving a definition from the body to a schedule, renumbering. These look innocuous and are frequently the most dangerous, because they silently break cross-references. If Section 7.2 becomes Section 7.3 and four other clauses say "subject to Section 7.2," the contract now says something nobody intended.
Definitional edits change what a defined term means. These are the highest-leverage edits in any contract, because a defined term can appear dozens of times. Changing the definition of "Confidential Information" in Section 1.1 changes the meaning of every clause that uses it, often across multiple related documents. Anyone who has watched a term like "Deliverables" quietly diverge into "Project Deliverables" and "Service Deliverables" across a Master Agreement and its Statements of Work knows how this goes wrong. If you want the deeper version of that failure mode, our piece on why defined terms break at scale covers it in detail.
Comments and queries are not edits at all. They are questions, flags, and explanations sitting in the margin. "Is this consistent with the SOW?" "Business team needs to confirm the SLA number." These carry the reasoning that the tracked changes cannot express.
Here is how a round actually runs when it runs well.
1. Establish the baseline. Before you edit anything, know exactly which version you are marking up. "The latest one" is not a baseline. A version identifier and a timestamp is. Most redlining disasters trace back to two people editing different baselines simultaneously.
2. Turn on change tracking before you type. Obvious, routinely forgotten. Edits made with tracking off become invisible changes, which is functionally indistinguishable from bad faith even when it is pure carelessness.
3. Make edits in passes, not all at once. Do a substantive pass first (the terms you actually care about), then a consistency pass (defined terms, cross-references, party names), then a formatting pass. Mixing them makes the redline harder for the other side to read and harder for you to explain.
4. Comment on anything non-obvious. If you cut a clause, say why in the margin. A redline without explanation invites the other side to simply revert it. A redline with a one-line rationale invites them to negotiate. The second is faster.
5. Run a blackline before sending. Compare your outgoing version against the version you received. This catches the change you made three days ago and forgot about, and the change your colleague made without telling you.
6. Send both the redline and the clean version. The redline is for review. The clean version is for reading the contract as it would actually operate. Sending only one always generates a request for the other.
7. Log what changed and why. Not in the document. In a place that survives the deal. This is the step almost everyone skips and almost everyone later wishes they had not.
The mechanics above are simple. They break for structural reasons, not because people are careless.
Version proliferation. A contract with three internal reviewers and one counterparty generates versions faster than anyone can name them coherently. The file naming convention degrades predictably: v2, v2_final, v2_final_JS, v2_final_JS_REVISED, v3_use_this_one. At that point nobody knows what the authoritative version is, and the answer usually has to be reconstructed from email timestamps.
Cross-references that do not know they are broken. Word treats "Section 7.2" as a text string. It has no idea that string is supposed to point at something. Renumber during negotiation and the reference silently becomes wrong. Nobody catches it because nobody re-reads the whole contract at round five. This is one of the few contract defects that is both extremely common and completely invisible until it matters.
Defined terms drifting across a document set. The MSA defines a term. The SOW uses it. The DPA uses a slightly different version. Redlining one document does not surface the effect on the others, because Word has no concept of a document set.
Accepting changes in bulk. Under deadline pressure someone hits Accept All. Every change made by every party, including the ones nobody reviewed, becomes part of the contract. This happens more than it should and is essentially unrecoverable once the clean version circulates for signature.
Comments getting stripped. Comments carry the reasoning. Converting to PDF or accepting all changes deletes them. The contract survives, the reasoning does not.
Microsoft Word is where the overwhelming majority of contract redlining still happens, and it is worth being honest about why: it is universal. Your counterparty has it. Their outside counsel has it. Nobody needs an account or a login. That interoperability is a genuine and underrated advantage, and any tool that ignores it is not a serious contender.
What Word does well: tracked changes are mature and well understood, the compare function generates reliable blacklines, comment threading works, and the format is a de facto standard for exchange.
What Word does not do: it has no model of document structure. A section is formatting, not an object. A cross-reference is text. A defined term is a capitalized word. A related document is a separate file with no relationship to this one. Every consistency guarantee you want has to be maintained by a human paying attention, and humans negotiating five deals at once stop paying attention.
Contract lifecycle management platforms address a different part of the problem. Tools in the CLM category, including Ironclad, Juro, LinkSquares, and Conga, focus primarily on the workflow around the document: intake, approval routing, storage, obligation tracking, and reporting. Several offer redlining features, typically through a Word add-in or a web editor. If your problem is that you cannot find your contracts or cannot see where a deal is stuck, that is the right category, and our overview of what CLM actually covers is a reasonable starting point.
The category HERO sits in is different again: the document itself as a structured object. Sections are real sections that know their own numbering. Cross-references are links that update when structure changes. Defined terms are entities with scope across a project, not capitalized strings. When you redline in that model, renumbering a clause updates the four references pointing at it, and changing a definition surfaces every document in the project that depends on it. You can see how that structure works on the features page.
None of these three fully replaces the others today. Most legal teams run some combination, and the honest answer to "which should I use" depends on whether your pain is finding contracts, moving them through approval, or keeping the language inside them internally consistent.
Redlines communicate more than their content. Experienced negotiators read them for posture.
Volume signals intent. A redline touching 8 clauses reads as a negotiation. A redline touching 60 reads as a rejection of your paper and an attempt to substitute theirs. If you genuinely need 60 changes, say so in the cover email rather than letting the document say it for you.
Silent reversion reads as bad faith. Reverting a previously agreed change without flagging it, especially without tracking, damages trust disproportionately to the change's importance. If you need to reopen something, reopen it explicitly.
Explanation accelerates. A redline where the ten most contentious edits carry a one-line rationale closes faster than one where they do not. You are pre-answering the question the other side would otherwise have to email you about.
Cleanliness signals competence. Formatting noise, stray tracked changes on whitespace, and half-finished edits make the substantive changes harder to find and make you look disorganized in a context where looking careful has value.
When markup lands in your inbox, work in this order.
Blackline it independently. Compare what they sent against what you sent. Do not rely on their tracked changes to be complete. This takes two minutes and periodically finds something significant.
Triage by risk, not by page order. Go straight to limitation of liability, indemnity, IP ownership, termination, and payment terms. Read the rest after. Reviewing sequentially means you spend your freshest attention on the recitals.
Check every definitional change against every use. If they touched Section 1, assume the effect is contract-wide until proven otherwise.
Verify cross-references if anything was renumbered. This is tedious and it is where the quiet defects live.
Separate what needs approval from what you can accept. Route the first to whoever holds authority. Do not batch a materially risky change in with twelve cosmetic ones and send the whole thing up as a single ask.
Respond to comments explicitly. An unanswered margin question comes back next round, having cost a full cycle.
If you want to reduce redlining pain structurally rather than heroically, the leverage is in three places.
Start from your own paper. The party whose template is the baseline does dramatically less redlining. Building a maintained template library is the single highest-return investment most legal teams can make, and it compounds. Our template library is a starting point if you are building from nothing.
Define your fallback positions before negotiation starts. A playbook stating your preferred, acceptable, and walk-away position on each key clause converts most redlining from a legal judgment call into a lookup. It also lets non-lawyers handle the routine rounds.
Fix the structural fragility. Cross-references that break, definitions that drift, and versions that multiply are not discipline problems. They are architecture problems, and discipline is an expensive and unreliable substitute for architecture. If your team is manually verifying that Section 7.2 still says what four other clauses think it says, that is a tool gap wearing a process costume. Our document workflow generator is a quick way to map where your current process leaks.
A redline is a document with authored tracked changes showing edits someone deliberately made. A blackline is a comparison document generated automatically by diffing two versions of a file. In current US practice the terms are used almost interchangeably, but the underlying distinction still matters operationally. You should always generate your own blackline against the last version you sent, rather than relying on the counterparty's redline to disclose every change they made.
Both, every time. The redline lets the other side review what changed without re-reading the entire agreement. The clean version lets them read the contract as it would actually operate, which is surprisingly hard to do while mentally accepting and rejecting markup. Sending only one reliably produces an email asking for the other, costing you half a day. Label both clearly with a version identifier so nobody has to guess which is which.
No, and it is worth being blunt about this. Untracked edits to a negotiated draft are functionally indistinguishable from concealment, regardless of intent. Even when it is pure carelessness, discovering an undisclosed change costs you credibility that takes several rounds to rebuild. If you realize you made untracked edits, the correct move is to disclose it immediately and resend with a proper blackline rather than hoping nobody compares.
For a standard commercial agreement on familiar paper, two to four rounds is typical. Enterprise deals, agreements with unusual risk allocation, or negotiations where both sides insist on their own template routinely run six or more. Round count is a poor quality signal on its own. What matters more is whether each round is narrowing the open issues or reopening settled ones. If round five is touching clauses that were agreed in round two, the problem is not the redlining process, it is that somebody's approval authority is unclear.
Accepting all changes under deadline pressure without reviewing them individually. It takes one click and it silently incorporates every edit the other side made, including any they made without flagging. The second most common is failing to check cross-references after a renumbering. Both are invisible at the moment they happen and expensive when they surface, which is a bad combination.
Parts of it. Comparison, consistency checking, defined term validation, and cross-reference integrity are mechanical problems that software handles better than people. Some tools now flag deviations from a playbook automatically, which usefully converts routine rounds into exception handling. What cannot be automated is the judgment about whether a proposed risk allocation is acceptable for this counterparty on this deal. Treat automation as a way to clear the mechanical work so a human can spend attention on the ten clauses that actually matter.
Somewhere that is not an email thread. The negotiation trail explains why the contract says what it says, and that reasoning is what you will need in two years when someone asks about an unusual carve-out or when the agreement is amended. Storing the executed clean version alone preserves the outcome and discards the reasoning. A contract repository or document platform that keeps version history attached to the agreement is the durable answer.
HERO is a document editor built for structured business documents, which means sections that know their own numbering, cross-references that update when structure changes, and defined terms that carry meaning across an entire document set rather than sitting as capitalized strings. If your redlining pain is less about the negotiation and more about what the negotiation does to the document, that is the problem we built for. Book a demo and bring your worst contract.