Drop your PDF into the zone below and every page comes back as a WebP image. At matching visual quality WebP lands a quarter to a third under a JPEG of the same page, and it handles the hard edges of type noticeably better on the way. That saving is aimed squarely at one job: page previews served inside a web browser. Choose the resolution, set a page range, take the result as one ZIP or as separate files. Nothing is uploaded and the encoder runs on your own processor.
Your files are read by JavaScript running on your own machine. There is no upload, no queue, and no copy on our server to delete later.
Drag a card to reorder it, or use the arrows under each card. The order here is the order in the output. Each card is a preview of the finished page, so what you see is what the PDF will contain.
Esc close ← → move R rotate
Starting
This is your processor doing the work, so the time it takes depends on your machine and not on how many other people are on the site.
The converter above is active and runs entirely in your browser. The guide below is written for anybody publishing document previews on a website. It covers where the size advantage over JPEG physically comes from at the block level, the one compatibility problem that still bites in 2026, how to derive a resolution from your CSS layout instead of from a printing standard, and when WebP is the wrong answer.
Two minutes, nothing to install, no account for your first run. This free PDF to WebP converter renders and encodes inside the tab you are reading, so every calculation happens on your own hardware.
Click the drop area above or drag the file anywhere onto this page. The document is parsed the moment it lands and the card shows page one with the page count, so you can confirm you loaded the right file before spending an operation.
For images going onto a web page, start from the CSS width of the container rather than from a print standard. A 400 pixel wide column needs about 800 pixels to stay sharp on a high-density screen, and 96 dpi renders an A4 page at 794 pixels wide, which covers it. 300 dpi is a print setting and has no place in a page preview.
Quality 85 is the baseline and looks the same as the source document at normal reading size. Drop to 75 when you are generating a grid of thumbnails and nobody will zoom in. Use the Pages field to convert only the sheets you actually intend to publish.
Press Convert to WebP. Compare the finished file against a JPEG of the same page at the same quality. On pages made mostly of text and diagrams the gap is wide, and every kilobyte of it comes straight off your page load time.
One conversion run counts as one operation, whatever number of pages it produced. An anonymous visitor gets one operation per 12 hours, a free CartHacker account gets two, and a batch carries 20 files or 100 MB in both cases. CartHacker Premium removes the operation counter and raises the batch ceiling to 100 files or 500 MB, which is what a product catalog turned into a wall of preview thumbnails actually needs.
The lossy half of WebP is a single still frame of VP8, a video codec. It arrived carrying tools that were built to compare one frame against its neighbors, and pointing those tools at a static page turns out to pay off handsomely. Three mechanical differences account for most of the drop in file size.
For anybody rendering PDF pages to publish, that adds up to a WebP a quarter to a third smaller than a JPEG that looks identical beside it. On contracts, reports and invoices carrying large flat areas the margin widens further, because flat space is precisely what intra prediction eats for free.
This is the part that matters most for documents. JPEG stores color at half the resolution of brightness, an optimization called chroma subsampling that saves real space on photographs. Put small dark letters on white paper and it produces colored fringes along every stroke. That is why a quality 70 JPEG of an invoice looks subtly grubby without anybody being able to say why.
The deblocking filter and the better edge handling mean WebP holds type together far longer as quality drops. Given a JPEG and a WebP of the same byte size, the WebP will look cleaner on any page containing typography.
It is still a lossy format. When the pixels have to be exactly what the renderer drew, with no degradation at all, use PDF to PNG instead.
Run the comparison on your own documents. Convert the same three pages to JPG at quality 85 and to WebP at quality 85, note the byte sizes, then zoom both to 200 percent on a paragraph. Your pages are not the average page, and thirty seconds of measurement beats any published ratio.
On the web the compatibility argument is over. Every current browser has decoded WebP natively for years. If the images are headed for a web page, an application interface or an HTML email template, use WebP and stop worrying about it.
Away from the browser the picture changes completely, and this is the thing to check before you commit to the format. A great deal of desktop and enterprise software still refuses to open or import a .webp file:
The rule is short. Images going into a web browser should be WebP. Images going to a person who has to double-click the file on their desktop should be JPG or PNG. Sending a client a file they cannot open costs more time in reply emails than the bandwidth ever saved you.
A PDF page is a set of drawing instructions and holds no resolution of its own. The pixel dimensions are produced at the moment you press convert, which makes the dpi setting a layout decision when the destination is a web page.
Work out how wide the image will actually display in its container, double it so it stays sharp on a high-density screen, then pick the dpi that gets you near that number. Every pixel beyond that is downscaled away by the browser, which means your visitors paid to download something they will never see.
| Rendered at | A4 page becomes | Comfortable web display width |
|---|---|---|
| 72 dpi | 595 x 842 | Up to 300 px, right for sidebar thumbnails |
| 96 dpi | 794 x 1,123 | Up to 400 px, standard content previews |
| 150 dpi | 1,240 x 1,754 | Up to 620 px, full article-width embeds |
| 300 dpi | 2,480 x 3,508 | Far past anything the web needs. A print setting. |
The middle column is what the browser downloads. The right column is what the visitor sees. Render an A4 page at 300 dpi and put it in a 320 pixel mobile column and you have shipped roughly fifteen times the pixels the screen can use. That single mistake is behind a large share of slow product and documentation pages, and it never shows up on a developer machine with a fast connection.
Most free PDF tools upload your document to a remote server, render it there, and hand you a privacy policy promising deletion afterwards. A policy is a promise. Promises evaporate when the operating company is acquired, when a backup is left exposed, or when somebody with database access has a bad month.
There is no upload phase on this page. The JavaScript here reads your file through the browser File API and renders and encodes every page on your own processor. The finished images come back through temporary object URLs that exist only inside this tab. No remote server takes part in the rendering, so no copy of your financial reports, contracts or customer data exists anywhere to be intercepted, retained or leaked.
You can prove this right now. Load this page, disconnect the machine from the internet, drop in a PDF and hit convert. A cloud-based tool fails immediately. This one carries on and hands you the WebP images.
The only thing that reaches our server is the operation counter enforcing the free tier. It records that a conversion happened and when. It never receives your file name, your page count, or a single byte of what the document contains.
On rendered PDF pages, a quarter to a third smaller at matching visual quality, and often more on business documents carrying large flat areas of white paper. WebP predicts each block from the decoded pixels beside it and stores only the difference, so a block of paper next to more paper costs almost nothing. JPEG encodes every block from scratch and pays full price for empty space.
Sharper than JPEG at the same file size. An in-loop deblocking filter smooths the block boundaries during decoding, so you avoid the hard grid squares and the colored fringing that JPEG leaves around small type. WebP is still a lossy format though. When the pixels have to match the render exactly, convert the PDF to PNG instead.
Yes, once the page has loaded. Loading this page needs the internet; the conversion itself does not, because the rendering and the encoding both run in your browser on your own processor. Drop your file, disconnect the Wi-Fi, press convert, and the WebP images still come out.
Derive it from your layout width rather than from a print standard. 96 dpi renders an A4 page at 794 pixels wide, which comfortably covers a 400 pixel content column on a high-density screen. 150 dpi gives 1,240 pixels and suits a full article-width embed. Choosing 300 dpi for a web image forces visitors to download pixels the browser will immediately throw away.
Inside a web browser, yes, every current one decodes WebP. On the desktop, frequently not: legacy image viewers, older office suites, enterprise document systems and commercial print pipelines still reject the format. If you are emailing a page image for somebody to double-click and open, convert the PDF to JPG or PNG instead.
Yes, and the reason is architectural rather than contractual. Your PDF is read, rendered and encoded by your own computer, and no file data is transmitted to us at any point, so there is nothing on our side to store, read or leak. Confirm it by disconnecting from the internet and converting anyway.
Yes. Type a range into the Pages field the way you would in a print dialog, such as 1-4, 9. Converting only what you plan to publish is the sensible habit here, because rendering pages you will never upload costs you processing time and gives you a folder to clean out afterwards.
Because the job exceeded the memory the tool is willing to ask your browser tab for. A single A4 page at 300 dpi is 8.7 million pixels and roughly 35 MB while it is being rendered, and the budget across a whole run is 900 million output pixels. The total is checked before any page is rendered, so the refusal costs you nothing. Lower the dpi or shorten the page range.
None. No hidden watermark, no logo, no trial banner and no forced attribution link. The WebP images hold what was rendered from your PDF and nothing else, and they are free for commercial and professional use.
Yes. A batch holds up to 20 files or 100 MB, and CartHacker Premium raises that to 100 files or 500 MB. Every page of every document is processed in a single run, and each output file is named after the source document with a zero-padded page number, so pages from different PDFs stay separated and sort correctly in the download.
All of these run the same way: your file is read by JavaScript on your own machine, the work happens on your processor, and the result is handed back to you as a download that never existed anywhere else.
Find the apps that slow your store down, by name and in milliseconds, then answer shoppers' doubts with trust badges under Add to cart. Both are free, with no card and no access to your store admin.
Paste any page and get its three Core Web Vitals, the apps costing time, like Klaviyo or Judge.me, and the Shopify or WooCommerce fix.
Show the promises that settle doubts, from free shipping to a money-back guarantee, right under the Add to cart button. One line in your theme.
Change the link after printing and count the scans. 5 tracked codes on a free account, static codes unlimited.
Anonymous visitors get one operation per 12 hours, per network address. That is not a sales tactic, it is the only lever we have: this tool runs on your processor, not ours, so the run itself earns us nothing. An account tells us who you are, and the ceiling goes up the moment you have one. Your allowance resets in 12 h.
No credit card, no trial period, no sales call. Join with Google, GitHub, Facebook or email.
Free accounts get two operations per 12 hours, and yours reset in 12 h. Waiting costs you nothing and is a completely reasonable choice. If PDF work is a weekly job rather than a one-off, the counter is the wrong tool for you and Premium takes it off the page.
Cancel anytime. Everything you have already produced stays yours either way.