Summarize a long PDF without hitting the limits

Because the AI jobs have three ceilings, and a long document hits at least one. The fix is to hand the Summarize PDF tool pieces instead of the whole file, and to cut the pieces with the page-range option or with Split PDF.

The ceilings:

• File size. About 5.7 MB per PDF for the AI jobs.
• Input length. A PDF counts as roughly 6,000 input tokens, so a very long document gets cut or refused rather than read to the end.
• Answer length. One answer is capped near 1,500 words, and on the free plan smart models get a shorter cap.

The quiet danger is the cut. If a long file is trimmed, the summary can only describe what it was given, so a smooth summary doesn't prove it covered all 300 pages. The working method is to choose a range, summarize that part, repeat, then merge.

The summary action in the AI panel has a page-range option. Enter the pages you want, for example 1-30, and the tool cuts those pages out on your device first. Only those pages are uploaded to the model provider you picked. The rest of the file stays where it is.

That gives you two things: the part fits under the limits, and you decide what leaves your device. Handy when one chapter is fine to share and another isn't.

One trap is page numbers. The range counts pages in the file, from the first page, not the numbers printed on them. If the report has a cover and a six-page table of contents, printed page 1 may be file page 8. Check which number your PDF viewer shows and use that one.

Also end ranges at a chapter break. A summary of pages 28-57 that starts mid-argument produces a mid-argument summary.

If you want the parts as separate files, or the original is over the size limit, use Split PDF. It runs in your browser with no upload, takes files up to 50 MB, and cuts two ways: every N pages, or custom ranges, with each result downloaded as its own file.

The page tiles show page numbers and rotation, not thumbnails, so find the chapter starts first. Open the PDF in your viewer, read the table of contents, and note the file page where each chapter begins. Then enter custom ranges such as 1-24, 25-58, 59-91, and name the downloads by chapter.

Chapters beat every-N-pages because the model gets a complete unit. A chapter has an argument and a conclusion. Pages 31-60 sliced across two chapters have neither. Use every-N-pages only when the document has no real structure, like a long run of meeting minutes. And check each part's size: text-heavy parts are usually small, but a part full of images can still be above 5.7 MB.

Say you have a 300-page annual report and a meeting tomorrow. This is an example, not a test result, but the workload is typical.

The table of contents shows ten chapters of about 25 to 40 pages. You split by chapter into ten files and run the same instruction on each, in key points style. After each run you paste the result into a notes document under the chapter title. On GPT-4o mini that's 1 Gem per part, so 10 Gems for the pass, with the cost shown before every run.

Using the same instruction every time matters. If part 3 gets "five bullets, numbers included" and part 4 gets "a paragraph", the merge turns into guesswork. Write the instruction once and paste it.

You end with ten short summaries of perhaps 150 to 300 words each. That's a 2,000-3,000 word notes file, still too long to read the night before. Hence the next step.

Paste the part summaries into a normal AI chat message and ask for one merged summary. It's a plain text message, so no PDF is sent, and the usual model tier applies.

Tell the model what the pieces are and what you want back. Keep the target well under the cap of about 1,500 words per answer; a 500-word merge is also much easier to check than a 1,400-word one.

Two cautions. A merge only knows what the part summaries kept, so a detail dropped in a part is gone. And a merge can smooth over contradictions, so ask it to flag them instead of reconciling them. When something in the merged text matters, go back to that chapter and ask a precise question (how to chat with a PDF covers the routine).

Short gives you a few sentences, enough to decide whether a part is worth opening. Detailed keeps the structure and more specifics, for when you won't read the source. Key points gives a list that's easy to scan and easy to paste into the merge step.

For the per-part pass on a long file, key points usually works well because lists survive merging. For one short document, short is enough. Unsure? Run short first and go up from there.

Summaries compress, and compression is where errors hide. Spot-check these:

• Numbers. Amounts, percentages, years, units. Open the source page and compare digit by digit. A model can swap 2023 and 2024 or drop a zero.
• Names. People, companies, places. A statement can end up attached to the wrong person.
• Negations and conditions. "Not required", "unless", "only if", "except". A flipped negation reverses the meaning and still reads smoothly.
• What's missing. Pick a section you know well and see whether the summary mentions it. If something central is absent, run again with an instruction that names it.

Pick the three or four claims you'll repeat to other people and verify those. Checking every line defeats the purpose. And if the long file is a contract, read understand a contract with AI first: summaries tend to drop the exceptions, and in a contract the exceptions are the point.