Render each page of a PDF as an image at the resolution you pick, then save them one by one or as a single ZIP. The document is read in this tab and never uploaded.
Runs in your browser. Nothing is uploaded.
Each page is drawn the way a PDF reader draws it. The page description is interpreted, fonts are laid out, vector paths are filled and any embedded images are placed, all onto a canvas at the scale you choose. At 2x that canvas is 144 dots per inch rather than the 72 a PDF point implies, which is why the output still looks sharp on a high-density screen. What comes out is a picture of the page: text is no longer text, and nothing in the result can be selected, searched or read by a screen reader.
The single biggest decision here is JPEG or PNG, and the gap is much larger than people expect. A 12-page scanned document rendered to JPEG at quality 90 produced 3,006,308 bytes across all pages. The same document at the same resolution rendered to PNG produced 23,899,262 bytes, eight times as much, for output that is visually identical on screen. On a text document it is starker still: a 40-page report of 165,897 bytes became a 25,256,591 byte set of PNGs, about 152 times its original size, because every page becomes a lossless raster of largely white paper. PNG is the correct choice when you need exact pixels for archival or further editing. For sending a page to someone, JPEG is almost always what you want.
Choose a PDF
The same questions a security review would ask, answered plainly.
1x, 2x or 4x, which is 72, 144 or 288 dots per inch. Higher settings are worth it for printing or for reading small print; 2x is enough for anything viewed on a screen.
Give a page range rather than the whole document. Rendering is the slow part, so converting three pages out of two hundred takes a fraction of the time and memory.
Each page gets its own download, and there is a Download ZIP option when you want the lot. A 12-page conversion is one file rather than twelve separate saves.
Rendering happens in the page using the same engine your browser uses to display PDFs. Nothing is transmitted, which matters when the document is a contract or a medical letter.
There is no upload step and no server to receive one. The page loads once, then all work on your PDFs happens in local JavaScript.
No daily limits, no per-file ceilings imposed by a server tier, no watermarks, and no account. The practical limit is your own device's memory.
Identical resolution, identical appearance, eight times the size.
The usual intent: pages you can attach, paste or upload somewhere that wants images.
Input
12-page scan, 10,324,119 bytes
Output
12 JPEGs, 3,006,308 bytes zipped
Settings: JPEG, quality 90, 2x (144 dpi)
Smaller than the PDF it came from, by 70.9 percent, because the source stored each page as a high-resolution scan and this re-encodes at screen resolution. Good enough to read, far easier to send.
The same conversion with only the format changed.
Input
12-page scan, 10,324,119 bytes
Output
12 PNGs, 23,899,262 bytes zipped
Settings: PNG, 2x (144 dpi)
Eight times the JPEG output, and larger than the original PDF, for pictures that look the same on screen. PNG earns that cost only when the pixels themselves matter, such as archival copies or images about to be edited repeatedly.
Real files, real numbers, and the machine they were run on.
| Scenario | Input | Output | Notes |
|---|---|---|---|
| 12-page scan to JPEG at 2x, quality 90 | 10,324,119 bytes | 3,006,308 bytes zipped | 70.9% smaller than the PDF |
| 12-page scan to PNG at 2x | 10,324,119 bytes | 23,899,262 bytes zipped | eight times the JPEG output |
| 40-page text PDF to PNG at 2x | 165,897 bytes | 25,256,591 bytes zipped | about 152 times the source |
How this was measured: Measured by driving this page in headless Chrome 152 on an Apple M4 Pro running macOS 15.5, on 2026-09-17. The fixture is handed to the page's own file input, the page's own button is pressed, and the figure recorded is the size of the file the page produces. Timings come from a warm page on a fast machine with no network involved, so treat them as a floor rather than a typical result.
Set the page range to just that page number before converting. Only the page you asked for is rendered, which is quicker than converting everything and deleting the rest.
Use 4x, which is 288 dots per inch, and choose PNG if the page contains line art or text. For screen use, 2x is plenty and costs a quarter of the memory.
Convert the page to JPEG at 2x and insert the image. Most presentation software handles a JPEG far better than an embedded PDF, and the file stays small.
This is not that. It renders whole pages, so you get the page with its margins and text rather than the original embedded image at its native resolution. Cropping the rendered page afterwards is the nearest route.
Recipients on a phone, or in a chat application that previews images but not documents, get something they can actually see without downloading and opening a reader.
Dropping a rendered page into a presentation avoids the embedded-PDF problems that show up when the deck is opened on another machine.
A print shop that wants images rather than a document can be given exactly what it asks for, at 288 dots per inch, without the file passing through any service in between.
Case files, statements and identification documents often need to be supplied as images. Rendering them locally keeps sensitive paperwork off third-party servers entirely.
Generating a cover image for a document listing is a one-page conversion at low resolution, which takes almost no time and produces a small file.
The rendering engine is part of the page once it has loaded, so conversions continue with no connection, which is also the simplest proof the document is not being sent anywhere.
Rendering a page is a one-way trip, and the first item is the one that catches people out.
An image of a page cannot be selected, searched, copied from or read aloud. If the point is to get the words out of a PDF, this is the wrong direction entirely and no resolution setting changes that.
A 166 KB, 40-page report rendered to PNG produced a 25 MB archive. The format defaults to PNG for fidelity, so switch to JPEG unless you specifically need lossless pixels.
Each page is drawn to a canvas at the chosen scale and kept until you leave. A long document at 4x will exhaust a phone quickly, so use a page range for anything substantial.
Pages are re-rendered rather than unpacked, so a photograph inside a PDF comes back at the resolution you rendered at, not the resolution it was stored at.
It does not. Pages are rendered by the PDF engine already running inside your browser, and the resulting images are built in the same tab. There is no request carrying your document at any point, and the conversion works identically with the machine disconnected from the network.
JPG for almost everything. On a 12-page scan, JPEG produced 3,006,308 bytes against PNG's 23,899,262 for output that looks the same on screen. Choose PNG when you need exact pixels, such as an archival copy or an image you will edit repeatedly.
They are multiples of a PDF's native 72 points per inch, so 72, 144 and 288 dots per inch. 2x is the right default for reading on a screen. 4x is for printing or for very small print, and uses roughly four times the memory of 2x.
Yes, set a page range instead of leaving it as all. Only those pages are rendered, so converting page 7 of a 300-page document is nearly instant and uses almost no memory.
Use the Download ZIP button that appears after conversion. It packages every rendered page into a single archive, which is much less tedious than saving twelve images one at a time.
At a high enough scale they will look the same on screen, but a PDF's text is vector and can be zoomed indefinitely while an image cannot. Zooming into a rendered page eventually shows pixels where the PDF would still show clean letterforms.
No, this goes the other direction. Rendering turns text into pixels, so the output contains no selectable text at all. Extracting words needs a text extractor or, for a scan, optical character recognition, and neither is offered here.
Because a PDF stores instructions and a PNG stores every pixel losslessly. A 40-page text document of 165,897 bytes became 25,256,591 bytes of PNG, since each page turned into a full raster of mostly white paper. JPEG avoids most of that.
No. The renderer refuses a document it cannot decrypt, and there is no place to type a password here. Open it in whichever reader you normally use, save an unlocked copy from there, and convert that instead.
Nothing fixed, because there is no server enforcing one. Memory is the constraint: every converted page is held as an image until you navigate away. Use a page range for long documents, particularly at 4x and particularly on a phone.
Yes, filenames carry the page number so they sort correctly in any file browser. A range such as 5-8 produces four files numbered by their position in the original document rather than renumbered from one.
Yes, after the page has loaded once. PDF rendering and image encoding are both done by your browser, so nothing more is needed from the network.
There is no limit imposed by us, because there is no server tier to enforce one. The real constraint is your device's available memory, since the whole file is held in RAM while it is processed. Very large files are slower on phones than on a laptop.
No. There is no sign-up, no email, and no usage tracking tied to an identity. The tool works the first time you open it.