PDF to WebP — a page-weight decision for people publishing document listings
If you publish a list of documents, each entry wants a small picture next to it, and file weight is a publishing decision, not a format preference. This route renders the page you select in the studio tab and encodes it as WebP at a fixed quality of 0.9. It is lossy: there is no lossless mode and no mode selector to switch on, so the honest workflow is to render, download, measure, and only then decide what goes on the page.
The page is flattened to pixels: selectable text, links and form fields become part of the picture and are no longer separate.
Processed on your device. Files aren’t sent anywhere.
The decision you are making
You are trading exact pixels for weight. The renderer draws the page onto a canvas, and the WebP encoder then compresses that canvas, throwing away detail it judges least visible. What you keep is a smaller file that still reads as the page; what you lose is any guarantee that a pixel in the file matches the pixel the renderer produced.
Lossy means lossy
There is no pixel-exact promise on this route. Flat colour areas and photographs usually survive cleanly; thin rules, small grey type and subtle gradients are where compression artifacts show up. If exactness matters — a proof, a print check, a pixel comparison — capture the page with the PNG route instead.
The controls you actually have are page choice (slider 1 through 40, or Every page) and render scale 1x / 2x / 3x, default 2x. There is no quality slider, so scale is how you control weight.
The pixel ceiling keeps the tab alive
Each frame is capped at 4,000,000 pixels and lowered automatically if your scale would exceed it, so a large page still exports rather than exhausting memory. Documents above 40 pages are rejected outright, and the input limit is 20 MiB for one file.
Measuring instead of guessing
- Export the first page at 2x, the default, and note the downloaded file's size.
- Export the same page at 1x and compare — scale is the weight lever on this route.
- Run the same page through PDF to PNG and compare the two files side by side.
- Open both at the size your listing will actually display them, and look at small type and hairline rules in the WebP version.
- Publish whichever passes your own readability check; keep the other export as the fallback.
- Compare bytes per displayed pixel, not bytes alone: a 1x export is smaller but may be too small to read.
- Judge the file at the size it will be shown, not at 100% zoom on your monitor.
- If the listing shows one thumbnail per document, exporting only page 1 is usually the right call; Every page produces one WebP file per page and multiplies your weight.
| Check | How to test it | Fail signal |
|---|---|---|
| Readability | Open the file at the listing's display size | Small type turns muddy or edges ring |
| Weight budget | Compare file sizes across 1x, 2x, 3x | Listing total exceeds your page budget |
| Faithfulness | Compare against the PNG capture | A colour or gradient visibly changes |
| Coverage | Decide page 1 versus every page | Every-page export multiplies weight needlessly |
When WebP is the wrong answer
- You need selectable text. An exported WebP is a flattened picture: no text layer, no font inventory, no embedded image objects inside the file.
- You need exact pixels. Use PDF to PNG; lossless encoding keeps the render as produced.
- You need transparency. A transparent export is not guaranteed; check the downloaded image against the background of your listing.
- You need to quote or search the page. Use PDF to TXT, PDF to JSON or PDF to HTML, which work on extracted text rather than pixels.
Weight is only worth trading for fidelity once you have measured both — a smaller file nobody can read is not an improvement.
The measuring rule for published page exports