• replace this text with your list
• begin each item with an asterisk

This list began after a finished file failed at the very last upload box.

## The things I notice before compression

### The destination limit

I look for the actual attachment or upload limit before deciding how small the PDF should become. “Smaller” is a vague ambition. “Below 25 MB” is a usable target.

If the file reaches 23 MB and remains clear, the task is complete. Reducing it to 5 MB may create a more dramatic percentage, but it does not improve the upload. It only spends more of the quality margin.

The destination gets the first word because the destination is where the problem exists.

### The role of the file

I ask whether I am holding a master or a delivery copy. The master should preserve the information needed for editing, printing, and future reuse. The delivery copy should move easily through a particular channel.

One PDF does not need to perform every job. A rich original and a lighter sharing version can coexist without either one being wrong.

This idea removed most of the anxiety from compression. I am not destroying the source. I am creating a derivative with a clear purpose.

### The objects that probably carry the weight

Page count is not a reliable explanation for file size. A long text document may be light, while a short portfolio with full-resolution photographs may be enormous.

I look for scans, phone photos, screenshots, detailed diagrams, and images placed at a small display size. Those objects often preserve far more pixel data than the reader needs at normal scale.

Text, fonts, and vector paths matter too, but large raster images are usually the first place worth understanding.

## The things I protect

### Searchable text

I select a sentence and search for an unusual phrase before processing. Afterward, I repeat the same actions.

Some crude methods turn every page into an image. The output can look nearly identical at one zoom level while losing text selection, search, links, and crisp vector scaling. A smaller file that becomes harder to use is not an uncomplicated improvement.

Searchable text belongs on my list because appearance alone will not reveal its loss.

### The smallest meaningful detail

Large headings are easy to preserve. Small labels inside screenshots, thin lines in technical diagrams, light handwriting, QR codes, and decimal values in tables are more fragile.

I choose a few pages containing those details and treat them as regression samples. They tell me when compression has gone too far much sooner than the cover does.

The best test page is not the prettiest page. It is the page most likely to expose a bad decision.

### Page order and navigation

I confirm that the page count and order remain correct. I try a table-of-contents link if the document has one. If the PDF includes intentionally different page sizes or orientations, I check those as well.

Compression should reduce weight, not quietly reorganize the document. These checks are boring in the reassuring way that seat belts are boring.

## The things I do during the actual task

### Begin with the middle

For a one-time delivery problem, I usually open

(https://pdfcompress.ai/) and start with medium compression. The result becomes evidence. If it is still too large, I try a stronger level from the original. If fine detail softens, I try a gentler one.

High, medium, and low are useful because they turn an invisible technical tradeoff into a short comparison. I do not need to pretend that one setting fits every document.

The browser page accepts files up to 1 GB, so a large source does not need to be split simply to enter the workflow. It can also process up to five PDFs together when a handoff contains related files.

### Keep each file’s identity

A batch is a convenience, not a declaration that every file is the same. A text-heavy guide may tolerate a different setting from a scanned appendix or a photographic catalog.

I group files when they share a destination and timing. I still inspect each result according to its content.

This is one of those distinctions that seems fussy until the day one appendix becomes unreadable while everything else looks fine.

### Wait for the real result

When processing finishes, I download the output immediately and open the actual file. A preview or a success message is not the artifact I will send.

The result should have no watermark. The compression tool belongs backstage; it should not introduce itself to the reader on every page.

For very large uploads, I also remember that the network is part of the wait. A generous file limit makes the task possible, but it cannot make slow upstream bandwidth disappear.

## The things I do afterward

### Name the copy for its route

I use names such as `report-email.pdf`, `portfolio-application.pdf`, or `manual-web.pdf`. The name explains why the derivative exists and reduces the chance that someone later mistakes it for the master.

I leave the original untouched. Every new attempt begins there, because repeated lossy processing can accumulate image damage and make comparisons unreliable.

Good naming is a small form of documentation.

### Test the actual destination

I upload the file to the portal, attach it to the message, or open it in the knowledge base that created the requirement. Meeting a theoretical target is not enough if the real system still refuses the file.

I also open it on a phone when mobile reading is likely. A PDF can feel entirely different away from office broadband and a large monitor.

The route is the final test because arrival is the purpose of the delivery copy.

### Stop when the goal is met

This may be the hardest item on the list. Optimization invites another attempt because another reduction is measurable. The budget gives me permission to stop.

If the file passes the limit, opens promptly, retains its structure, and keeps the sample pages readable, unused space below the limit is not waste. It is a cushion protecting quality.

## The things this list helped me remember

### Compression is not the same as deletion

I do not need to remove pages or weaken the master just because one route has a narrow doorway. A delivery copy can carry the same document with a different data budget.

The distinction is practical, but it also changes the feeling of the task. Compression becomes preparation rather than punishment.

### Tools should match frequency

An occasional, human-reviewed handoff fits a browser tool. A recurring flow with hundreds of predictable files deserves automation, fixed policies, logging, and tests.

I try not to build a pipeline for one attachment, and I try not to perform a production pipeline by hand. Proportion is part of good tool choice.

### A quiet arrival is the real outcome

The reader should notice the report, portfolio, guide, or application. They should not notice the struggle that occurred between export and upload.

That is why this remains a list of decisions rather than a list of compression tricks. The technical operation is short. Knowing the target, protecting the right details, and stopping at the right moment are what make the result dependable.