Comparing Multiple Documents Side by Side
Most people comparing two documents with Claude do it in two separate steps: paste the first one, ask for a summary, paste the second one, ask for another summary, then try to line up the two summaries themselves to see what's different. That works, but it pushes the actual comparison, the part that takes real judgment, back onto you.
Tip
Ask for the comparison directly. Claude can hold both documents in the same conversation and compare them against the same criteria in one pass, which is a different and better result than two summaries you have to cross-reference yourself.
A comparison is not two summaries stapled together. It's one answer to the same question, asked of two different sources.
Why two summaries aren't a comparison
When you ask for two separate summaries, Claude has no reason to organize them the same way. One summary might lead with pricing, the other with timeline, because that's how each document happened to be structured. Lining them up afterward means you're doing the actual comparative work yourself, the part that was the point of asking in the first place.
Picture two vendor proposals for the same contract. One is organized by service tier, the other by monthly cost breakdown. Summarized separately, you'd get two documents that don't share a shape, and you'd have to manually hunt through both for anything about implementation timeline, or support hours, or contract length. That hunting is exactly what a real comparison should skip, and it gets worse the more documents you add: three or four separate summaries multiply the cross-referencing instead of simplifying it.
Before: paste in document one, summarize it. Paste in document two, summarize it. Read both summaries and try to spot the differences yourself.
After: upload both documents in the same conversation, name the specific criteria you care about, and ask for one answer that addresses both documents against every criterion.
A process for a real comparison
- 1
Upload or paste both documents into the same conversation
Claude needs both documents present at the same time to compare them directly. Uploading them one after another in the same thread works; starting a new conversation for the second one does not, since Claude cannot compare something outside its current context.
- 2
Name the specific criteria before asking for the comparison
List what you actually want compared: price, timeline, scope, cancellation terms, whatever matters for this decision. An open request like "compare these" gets you whichever criteria Claude guesses matter, which may not be the ones you actually care about.
- 3
Ask for a structured format, not prose
Request a table, or a criterion-by-criterion breakdown, with each document's answer sitting next to the other's. A paragraph-style comparison still makes you hunt for the piece you need; a table puts both answers in the same row.
- 4
Ask it to flag anything one document doesn't address
Two documents rarely cover the exact same ground. If one proposal is silent on cancellation terms and the other spells them out in detail, that gap is itself useful information, and it's easy to miss if you're not asking for it directly.
I'm comparing two vendor proposals for a one-year software contract. Compare them in a table across these four criteria: total annual cost, implementation timeline, included support hours, and cancellation terms. If either proposal doesn't address one of these, say so in that cell instead of leaving it blank.
”This works whether the two documents are structured the same way or not. Claude reads each one for the criteria you named, not for whatever section headings the original author happened to use, so a proposal organized by service tier and one organized by monthly breakdown still land in the same table, row by row.
Inside Claude Tutorial
Naming the criteria before asking is the transferable part.
Comparing by named criteria instead of letting the source material set the terms works for more than documents. It's one of several reusable habits the app builds through short, hands-on lessons.
When the documents disagree
Sometimes a comparison surfaces a real conflict: one proposal claims same-day support, the other claims a 24-hour response window. You want that flagged clearly, not smoothed over into an averaged description that hides the disagreement.
Common mistake
Asking for a single merged summary of both documents. That format hides exactly the differences you were trying to compare in the first place; a side-by-side format preserves them.
Where the two proposals give conflicting information on the same point, call it out explicitly in the comparison instead of picking one version or averaging them.
”A useful comparison also tells you when it can't find something. If neither document mentions data retention policy and that matters for your decision, Claude saying "not addressed in either document" is a more useful answer than silently omitting that row.
Comparing more than two documents
The same approach scales past two. Three or four vendor proposals, a handful of drafts of the same policy, a set of candidate resumes: the criteria-first, table-format approach still holds. The only real change is that the table gets wider, one column per document, which stays easier to scan than reading four separate summaries back to back and trying to hold all of them in your head at once.
Compare all four attached proposals in one table, using the same four criteria as before. Sort the rows by which proposal scores best on total annual cost.
”Once you have a comparison table you trust, it's worth keeping the same criteria list for the next comparison of the same kind, a habit covered later in this path.
Continue reading
- Summarizing a Long Document Without Losing What Matters: the single-document version of this skill, useful groundwork before comparing more than one.
- Comparing Two Financial Decisions Side by Side: this same named-criteria comparison technique, applied to a real financial decision.
- Turning Raw Notes Into a Clean List of Action Items: another everyday task that benefits from asking for a specific, structured output instead of open-ended prose.