Nobody thanks you for a shorter PDF, but everybody notices a bloated one. A reader who opens a 60-page attachment for a decision that needs six pages will skim, miss things, and quietly resent the sender. Trimming a document before you send it is therefore not tidiness for its own sake. It is a way of respecting the reader's time, and it often improves the decision you get back, because the reader actually reaches the pages that matter.

The trimming itself is simple. Remove Pages drops the pages you name and keeps the rest in order, producing a new file while your original stays untouched. The hard part is deciding what goes, and that decision deserves more care than the few seconds the tool itself takes. This post offers a pre-send routine you can run on any report, proposal, or pack before it leaves your hands.

Start from the reader, not from the document

Most trimming goes wrong because it starts from the document's structure: keep the introduction, keep the methodology, keep the appendix, because that is how the document was built. Start instead from the reader's job. What decision will they make, or what action will they take, after reading this? Which pages carry the information that decision needs? Everything else is a candidate for removal, however well written it may be.

A practical way to do this is to write the reader's question at the top of a page. For a budget approval, the question might be: "Should we approve this spend, and what does it cost?" The pages that answer it are the summary, the cost breakdown, and the risks. The full methodology, the vendor comparison tables from three rounds ago, and the glossary are not needed for that decision, even though they were needed to produce it. They can stay in the master copy and leave the sent copy.

This reader-first lens also protects you from a common trap: trimming only the obviously blank pages and calling the job done. Blank pages are worth removing, but they are the smallest win. The real win is the twenty pages of background that a busy reader will never reach, sitting between the summary and the recommendation and burying both.

The four questions to ask about each section

Work through the document section by section and ask four questions. First, does the reader need this to act? If not, it is a removal candidate. Second, is this information already available to the reader elsewhere — in a previous email, a dashboard, a contract they hold? Duplication across documents is a frequent source of bloat, and the sent copy does not need to repeat what the reader already has. Third, is this page current? An outdated chart or a superseded terms page is worse than a missing page, because it invites a decision based on old information. Fourth, is this page here for completeness rather than for use? Completeness is a virtue in an archive, not in a decision pack.

Be honest about the fourth question, because it is where authors resist trimming most. A section you spent a week writing feels wrong to cut, even when you know the reader does not need it. Remember that cutting it from the sent copy does not delete it from existence. The master document remains, the work is preserved, and the reader gets a document they can actually finish. If a reader asks for the background later, sending it then is a better outcome than burying it in the first send.

Worked example: a fictional funding proposal

Consider a fictional proposal prepared by a fictional consultant, Daniel Okafor, for a fictional community centre at example.org. The full proposal is 42 pages: a two-page summary, a needs assessment, a project plan, a budget, a risk section, three appendices of supporting data, and a set of draft letters of support.

The reader is a fictional grants officer who must decide whether the project meets the fund's criteria and whether the budget is sound. Daniel works through the document with that reader in mind and makes these calls:

  • Keep: the summary (pages 1-2), the needs assessment in short form (pages 3-8), the project plan (pages 9-18), the budget (pages 19-24), and the risks (pages 25-27).
  • Remove: the first appendix of raw survey responses (pages 28-34), because the needs assessment already summarises them and the raw data can follow on request.
  • Remove: the draft letters of support (pages 38-42), because signed letters will replace them and drafts add nothing to the decision.
  • Keep: the second appendix, a one-page eligibility checklist (page 35), and the third appendix's summary table (pages 36-37), because the officer checks eligibility against them directly.

The removal list is 28-34 and 38-42: twelve pages, leaving a 30-page decision pack. Daniel runs it through Remove Pages, then checks the result at each join: does page 27 still flow into the old page 35, and does the document end cleanly on the old page 37? He also re-reads the summary to confirm it does not promise an appendix that is no longer in the file — a small cross-reference error that trimming often creates and that a final read catches.

If the trimmed file then needs to travel with other documents, Merge PDF can join them in the order a reviewer expects, and Compress PDF can bring the result under an email size limit. Both are separate steps, and both are easier on a trimmed file than on the original.

Mistakes to avoid on send day

The most damaging trimming mistake is removing a page the reader was told to expect. If your email says "see appendix B," appendix B must be in the file. Check every cross-reference in your covering message against the trimmed document, not against the original. The second mistake is trimming a signed or version-controlled document without noting the change: if the recipient compares page counts with a previous version, an unexplained drop looks like an error. A single line in your message — "sent copy trimmed to the decision sections; full version available on request" — prevents that confusion. The third mistake is trimming under time pressure without checking the joins. A document that jumps from page 27 to page 35 without explanation is fine if the removed material was genuinely irrelevant, but a jump caused by a mistyped range is not. The check takes two minutes. Take them.

For guidance on comparing versions of a document before and after a trim, see the guide on comparing documents.

Honest limitations

Remove Pages deletes whole pages only: it cannot trim a paragraph from an otherwise essential page, and it cannot judge whether a section is truly unnecessary — that judgement is yours, based on the reader's job. It refuses to remove every page, so at least one page remains. Deleted pages are gone from the output copy, not hidden, so keep the master file and check the joins in the result before sending. Finally, trimming does not fix a document whose problem is unclear writing rather than excess length; if the kept pages are confusing, a shorter confusing document is not an improvement.

FAQs

How do I decide which pages to remove before sending a PDF?

Start from the reader's decision or action, not from the document's structure. Keep the pages that decision needs, and treat background, duplicated, and outdated material as removal candidates. Keep the master copy so nothing is lost.

Should I tell the reader I trimmed the document?

Yes, with one line in your covering message. It prevents confusion when page counts differ from an earlier version, and it invites the reader to ask for the full version if they need it.

Can removing pages break cross-references in my document?

Yes, if the summary or contents promises a section you removed. After trimming, re-read the summary and check your covering message against the trimmed file, not the original, before sending.

Does trimming a PDF make it much smaller?

Only by the size of the removed pages. If the trimmed file is still too large to send, compression is a separate step, and it comes with its own quality trade-offs to consider.

human review pending client designation