How do I record the steps I use to compress a PDF to a size?

Write down the source size, the target MB you enter, the fact that the run is local in the browser, the bounded profile sequence the tool attempts, and the actual saved byte length after the verification step runs.

Why does the documented procedure record the actual saved size rather than an estimate?

Because the tool only releases a download when the verified saved file is at or below your target MB, so the actual saved size is the only objective success criterion the procedure can capture.

What should I include in the runbook about the compression profiles?

Record that the tool walks a fixed bounded sequence — quality 0.70 at 1400 px, then 0.55 at 1000 px, then 0.40 at 800 px, then 0.30 at 600 px — and stops there, so the procedure does not depend on any settings outside that list.

Should the runbook state which image streams are eligible for replacement?

Yes. Document that the tool only replaces unmasked DCTDecode DeviceRGB or DeviceGray JPG streams with no decode parameters, that it leaves images alone if a recompression would grow them, and that it preserves unsupported objects, vectors, text, links, and form fields.

What should the runbook say when the tool produces no download?

Record the explanatory message exactly as shown, note that the source may be text-only, vector-heavy, or dominated by unsupported images, and record the target that was entered so the next run can be planned around the same constraint.

Document the Steps to Compress a PDF to a Target Size

Document the steps for compressing a PDF to a target size by recording the exact inputs (source file, target in MB), the bounded sequence of JPG quality and dimension profiles the tool attempts, and the verification gate that releases a download only when the actual saved file is at or below the requested MB. A clear runbook should also capture the limits of the operation — source size, eligible image count, total decoded megapixels — so the procedure explains in advance when no result will be produced. Because the tool checks the real byte length of each saved candidate against the target instead of estimating from the source, the documented steps can include a verifiable success criterion rather than a hopeful guess. Finally, the record should describe which objects stay untouched (page structure, selectable text, links, forms, vectors, unsupported images), so the documented outcome is honest about what changed and what did not.

how do i document the steps i use to compress pdf to size — Document the Steps to Compress a PDF to a Target Size

Why a documented compression procedure is worth writing down

Most "how to compress a PDF" guides describe a single attempt and stop. When the same task has to be repeated — by you next month, by a colleague, or as part of an audit trail — the value shifts from the run itself to the written record of the run. A documented procedure lets a reviewer see which inputs were used, which settings were tried, and what was actually produced without having to redo the work. For size-constrained targets (an email attachment cap, a portal upload limit, a regulator's submission size), the record is most useful when the documented success criterion is the actual saved byte count, not an estimate derived from the source file.

Writing the steps out also makes the procedure honest about its scope. The Compress PDF to Size tool is a target-aware local compressor that tries bounded JPG recompression: it does not promise lossless optimization, it does not rasterize whole pages, and it does not claim every input will reach every target. A runbook that captures those boundaries up front is far more useful to a teammate than a one-line instruction that quietly fails on the wrong file type.

What the documented procedure needs to record

A useful runbook for compressing a PDF to a target size should record five pieces of information so the procedure can be repeated or audited:

The source file name and its original size in MB.
The target size in MB that the operator entered.
The fact that the run happened locally in a browser — no upload, no server-side processing.
The bounded profile sequence the tool is allowed to attempt (documented in the table below).
The actual byte length of the saved file at the end of the run, or the explicit message that no download was produced.

The fourth item deserves its own table because the tool does not search unbounded settings — it walks a fixed short sequence and stops. Each candidate JPG is encoded using the WHATWG canvas toBlob method, which is why the values are stable and reproducible across browsers.

Profile	JPG quality	Longest-side (px)
1	0.70	1400
2	0.55	1000
3	0.40	800
4	0.30	600

A documented procedure that lists these four profiles in order lets a reviewer understand exactly how aggressive each attempt was, and lets you explain to a stakeholder why the run terminated at a given profile. Because the sequence is bounded, the procedure also documents an upper bound on browser work — there is no hidden fifth attempt that might surprise a reviewer later.

The documented steps for compressing a PDF to a target size

Follow these concrete steps in order when documenting (and performing) a target-size compression with the Compress PDF to Size tool. Each step records information that should be written into your runbook.

Note the source file path and confirm its size is at most 25 MB. Sources larger than the limit cannot be processed; record the size in MB in the runbook so a reviewer can verify the gate was satisfied.
Open the Compress PDF to Size tool in a desktop browser. Because the tool reads, decodes, recompresses, and verifies the PDF locally, document that no upload occurs — the file never leaves the device.
Choose one local PDF from the file picker. The tool accepts a single file per run, so the runbook should specify a per-file procedure rather than a batch one.
Enter a target size in MB between 0.1 and 25. The target must be smaller than the source file's byte length or the run will not start. Record the target value in the runbook exactly as entered, including decimal precision.
Select Compress to target size. The tool will attempt the bounded profile sequence from the table above, in order, replacing only eligible JPG image streams inside the PDF.
Wait for the verification step. The tool saves each candidate, compares its actual byte length to the target, and reopens the first candidate that passes through PDF.js (see the Mozilla PDF.js API) to confirm page count before exposing a download link.
If a download link appears, click it and save the resulting PDF. Record the actual saved file size in MB next to the target so the runbook shows the verified outcome, not an estimate.
If no download appears, record the tool's explanatory message in the runbook (covered in the last section of this article) so the next operator knows why the procedure stopped without producing output.

Recording what the tool does and does not touch

A faithful runbook records the scope of the change, not only the file size delta. The tool only changes embedded JPG streams that can be safely replaced: unmasked DCTDecode DeviceRGB or DeviceGray images with no decode parameters. If a candidate JPG would be larger than its original stream after recompression, the tool leaves that image untouched. It does not rasterize whole pages, it does not rewrite vectors, and it does not strip selectable text, links, or form fields. Unsupported image objects (such as images using a mask, decode parameters, alternative color spaces, or non-JPEG filters) are preserved in place.

The following table summarizes the documented eligibility rules so the runbook can state them precisely.

Stream category	What the tool does
Unmasked DCTDecode DeviceRGB JPG	Recompresses against each profile if the new stream is smaller
Unmasked DCTDecode DeviceGray JPG	Recompresses against each profile if the new stream is smaller
JPG where recompression would grow the stream	Leaves the original stream in place
Masked JPG, JPG with decode parameters, non-RGB/Gray, non-DCT	Preserves the original object unchanged
Page structure, text layer, links, form widgets, vectors	Not modified

Documenting these rules up front prevents a reviewer from assuming the run is "lossless" or from missing cases where the document had eligible images that were simply skipped because no profile beat the original size.

Verifying the saved file and storing the record

Verification is the part of the procedure that justifies the word "documented." Because the download is gated on a real byte-length comparison and a PDF.js page-count check, the saved file can be re-opened by any standard PDF viewer to confirm two simple properties: the page count matches the source, and the saved file size is at or below the recorded target. For a deeper checklist on post-run checks, see the result-checking guide.

For the runbook itself, store:

The source filename and size.
The target MB entered.
The actual saved MB.
The profiles attempted (recorded automatically by the tool's bounded sequence, but worth copying into the runbook).
A short note on whether any embedded JPG streams were skipped because they could not be safely replaced.
A note on whether the document was text-heavy, vector-heavy, or image-heavy, since that drives the realistic target range.

This stored record lets you or a colleague reproduce the run weeks later, compare against a different source, or hand the procedure off to operations without losing context.

When the documented procedure ends without a download

The runbook should anticipate the case where the tool produces no download. The Compress PDF to Size tool does not promise that every input will reach every target; if the resulting file is still over the entered target after every bounded profile, the tool creates no download and explains that the target cannot be reached safely. For a broader look at when targets fail, see the target-feasibility guide. Common reasons, which should each appear in the documented procedure:

The source PDF is text-only or vector-heavy, with few or no eligible JPG streams.
The eligible JPG streams are already small enough that no profile beats the original byte length.
The target is lower than the safe JPG recompression can deliver for that source.

In each case, the documented record should capture the explanatory message returned by the tool, plus the source characterization (image-heavy vs text-heavy). That makes the failure mode repeatable and reviewable rather than a one-off "it didn't work" note, and it lets future runs be planned against the same constraint instead of rediscovering it.