PDF to JPG — building previews where weight matters more than exact pixels
A document archive needs thumbnails, and thumbnails need small files. This route draws the page you chose onto a canvas in the studio tab and hands the result to the browser's JPG encoder at a fixed quality of 0.9. There is no quality dial on this page, which means the size of the picture you ask for is the only lever you have — and the cost of lossy encoding is something you should inspect before committing a gallery to it.
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.
What the encoder actually does
The page is executed onto a pixel grid first, exactly as the PNG route does. The difference is the last step: instead of storing those pixels losslessly, the encoder compresses them, discarding detail that it judges least visible. That is a real trade, not a cosmetic one.
| Control | Available settings | Effect on the output |
|---|---|---|
| Page choice | Slider 1..40, or Every page | One JPG for the chosen page, or one per page |
| Render scale | 1x, 2x, 3x (default 2x) | Pixel grid size, therefore file weight |
| Quality | None — fixed at 0.9 | Compression strength is decided by the route, not by you |
Where 0.9 shows up in the picture
- Flat colour areas survive well. A page that is mostly solid blocks, rules and simple shapes compresses with almost nothing visible lost.
- Thin type and high-contrast edges are the casualties. Small grey text on white, hairline table borders and tight letter spacing can pick up faint ringing around the edges.
- Check photographs as well as type. JPG often suits continuous-tone imagery, but photos already compressed inside the PDF undergo another encoding step. Inspect the downloaded result for visible damage.
- The output is lossy, so pixels are not guaranteed to match the render. If you need the exact pixels the renderer produced, use the PNG route.
- Colour banding on subtle gradients can appear. A soft background wash may show faint steps rather than a smooth ramp.
Inspecting a page before you commit the gallery
Render the page once at 1x and once at 2x, then zoom both in your own viewer. If the ringing around small text bothers you at the size people will actually look at, the fix is a larger render scale, not a higher quality setting — there is no higher quality setting here.
A frame is capped at 4,000,000 pixels and lowered automatically if your scale would exceed it, so a poster-sized page still produces a preview instead of exhausting the tab.
Questions about JPG previews
Can I set the JPG quality?
Does every page produce its own file?
Will the JPG contain the document's text?
JPG versus the other capture routes
| Page content | Better route | Why |
|---|---|---|
| Mostly photographs or scans | PDF to JPG | Lossy compression suits continuous tone and keeps weight low |
| Dense small typography | PDF to PNG | Lossless storage keeps edges crisp where JPG rings |
| Pages you want as compact as possible | PDF to WebP | A different lossy codec, judged by weight rather than by assumption |
| Pages you need to search or quote | PDF to TXT or PDF to JSON | Those routes extract text instead of painting it |
A preview is a judgement call: you are trading exact pixels for weight, and the trade is made once, at encoding time.
Why the fixed quality is worth inspecting rather than tuning
Deciding which pages deserve a preview
Previewing every page of a long document is rarely the right move. The first page usually carries the title block and the summary, so it does the job of a thumbnail on its own; Every page is there when you genuinely need a strip, such as a slide deck index or a scanned contract where each page is a distinct artefact.
Remember that a JPG preview is a flattened picture: the text inside it is painted, not selectable, and no fonts or embedded image objects travel with the file. Previews are for looking, not for reading.