Render PDF pages at a resolution you set in dpi
Initializing in your browser…
Turn pictures into a PDF at the size on paper you choose. Set the resolution a pixel count prints at, pick the paper, and see every page size and the resolution it prints at before anything is written.
Convert between the formats a browser can really write, then open the output and name the format its first bytes say it is. AVIF, BMP and GIF are disabled because a canvas returns a PNG for all three.
Drop pages from a PDF, or keep only the ones you choose
You need page 5 of a 24 page report as a 300 dpi picture for a slide.
Input
report.pdf · page 5 · 300 dpi · PNG
Output
One 2550 by 3300 PNG, rendered in 56 ms rather than 431 for the whole document
The resolution is dots per inch and the pixel size is its arithmetic consequence, round(612 x 300 / 72) by round(792 x 300 / 72), stated on the page before anything runs. Rounding rather than truncating matters on any page whose size is not a whole number of points: A4 at 72 dpi is 842 pixels tall, not 841. And only the page named is rendered, where the previous version rendered all twenty four and discarded twenty three.
Turn PDF pages into PNG, JPEG or WebP pictures at a resolution you set in dots per inch. The pixel size each page will come out as is shown before anything runs, per page, so a document of mixed paper sizes holds no surprises. Only the pages you name are rendered. A rotated page comes out the way a reader sees it, and the quality setting really reaches the encoder. Download one page as a file or the lot as a ZIP with the members in page order. Everything happens in your browser and nothing is uploaded.
Render the page you need at 150 dpi and paste the picture in, rather than screenshotting it.
Render at 300 dpi, which is what a printer asks for, and check the pixel size the page states before you commit.
Render at 72 dpi as JPEG for a set of small previews at a fraction of the size.
A picture of a page opens anywhere. Note that its text is no longer selectable.
A Letter page at 300 dpi comes out 2550 by 3300 pixels, which is round(612 x 300 / 72) by round(792 x 300 / 72), and the page says so before it runs.
Letter, A4, Letter landscape and A5 at 72 dpi come out 612x792, 595x842, 792x612 and 420x595: the nearest whole pixel to each, where truncating gives 595x841 and 419x595.
Naming page 5 renders page 5. It takes 56 ms against 431 for the whole document, where the previous version rendered all twenty four and threw twenty three away.
The resolution is set in dots per inch, because that is the number a person has. A scale factor is what a library wants, and the two are easy to confuse: a Letter page rendered at 150 dpi is 1275 by 1650 PIXELS while the page is still 612 by 792 POINTS. Here the pixel size is an arithmetic consequence of the dpi, `round(points x dpi / 72)`, and the page prints it before anything runs, per page, so a document of mixed paper sizes shows what each one will come out as.
That rounding is not decoration. A4 is 595.28 by 841.89 points, and assigning that straight to a canvas TRUNCATES: the page came out 595 by 841 where 595 by 842 is the nearest whole pixel, and every page whose size is not a whole number of points lost up to a pixel a side at every resolution.
Only the pages you ask for are rendered. That sounds obvious and was not: the previous version rendered the whole document and then discarded the pages it had not been asked for, so getting ONE page of a twenty four page document cost 108 percent of the time of getting all twenty four. It is now 13 percent.
A rotated page comes out the way a reader sees it, because pdfjs applies the /Rotate entry when it builds a viewport: a Letter page at /Rotate 90 renders 792 by 612, landscape.
The canvas is filled white before every render. A PDF page is white where nothing is drawn and a canvas is TRANSPARENT, so a page encoded as JPEG without that fill comes out black. And the quality setting really reaches the encoder, which the previous version's did not: it carried a quality state that nothing read, with no control in the interface either, and encoded everything at 0.92.
Which formats the browser can write is measured rather than assumed, because `canvas.toBlob` falls back to PNG for a type it cannot write and says nothing about it. A format this browser cannot produce is disabled rather than silently handing you a PNG named .webp.
300 dpi is what print means. 150 is good on screen and a quarter of the file size. 72 gives the page at its own dimensions, one pixel per point. The page tells you the pixel size for whatever you pick, before you render anything.
Yes, and only that page is rendered. Name it in the page range box. On a twenty four page document that is about a thirteenth of the work of rendering the lot.
JPEG for anything with photographs in it: at quality 90 a page of type is still crisp and the file is often a tenth of the size. PNG when you need it lossless or the page is line art and text only.
Because A4 is 841.89 points tall and 842 is the nearest whole pixel at 72 dpi. Truncating gives 841 and loses most of a pixel row, which at higher resolutions loses more.
No. A rendered page is a picture and the words in it are pixels. If the text is what you want, use the PDF Text Extractor; if you want the photographs the document embeds rather than a render of the page, use the PDF Image Extractor.
It comes out the way a reader sees it. A Letter page carrying /Rotate 90 renders 792 by 612, landscape.
PDF parsing and editing happen in your browser. Documents, and everything inside them, are never uploaded or stored remotely.