PDF to WebP

What PDF to WebP actually does

A PDF is a vector layout — instructions for drawing each page. WebP is Google's modern bitmap format, designed to do what JPG and PNG do, but smaller. Converting a PDF to WebP means rendering: each page of your PDF is drawn fresh onto a canvas at the resolution you pick, then encoded as WebP. The PDF to WebP Converter gives you one WebP file per page. A 50-page PDF becomes 50 WebPs, numbered in reading order.

WebP is the right answer when the images are going on the web. It does both lossy and lossless compression, and at the same visual quality it's typically 25-35% smaller than JPG and 50-70% smaller than PNG. For a website that embeds rendered PDF pages — a documentation site, a product catalog, a contract preview, a CMS that doesn't render PDFs natively — that page-weight saving compounds across dozens or hundreds of images and shows up directly in your Lighthouse score.

The trade-off used to be browser support. That trade-off has expired. Every browser shipped since 2020 supports WebP natively: Chrome since 2010, Firefox since 2019, Edge since 2018, Safari since 2020, Opera since forever. If your audience is on a phone, a tablet, or a laptop bought in the last five years, WebP works. If you're shipping to enterprise IT environments still running IE11, fall back to PDF to JPG.

How to use it

The PDF to WebP Converter runs entirely in your browser. Your PDF never uploads. Drop a file, pick a DPI and a quality, click convert.

1. Drop or pick your PDF. Up to 100 MB, max 200 pages.
2. Choose the output resolution (72, 150, or 300 DPI) and WebP quality (55%, 75%, or 90%). WebP's compression is more efficient than JPG, so even 75% usually looks identical to the source.
3. Click Convert to WebP. Each page renders to a canvas and exports as WebP. Progress shows per-page. Each thumbnail in the result grid shows its individual file size.
4. Download individual pages with the per-thumbnail buttons or click Download all to grab everything in sequence.

No account. No email. No watermark. No 5 MB cap. iLovePDF, SmallPDF, PDF24, Sejda — they'll all happily convert your PDF to WebP and then ask you to subscribe before you can do a second file, and they upload your document to their servers first to do it. Convertio and CloudConvert do the same thing with extra steps. We chose differently: the rendering work runs in your browser, on your CPU, using Mozilla's PDF.js. The WebP encoding uses your browser's native canvas.toBlob. Open developer tools, switch to the network tab, run a convert. Zero outbound requests.

Why WebP is smaller

WebP's lossy mode is based on the VP8 video codec's intra-frame compression. Without getting into the details, it's a generation newer than JPG's algorithm and predicts pixel values more cleverly, leaving less work for the entropy coder. The result, at the same visible quality, is consistently 25-35% smaller files. For pages that are mostly text or line art, the gap can be bigger — WebP handles flat color and sharp edges better than JPG.

Those numbers are for a typical office page — mixed text and graphics on white. A photograph-heavy page narrows the WebP-vs-JPG gap; a text-heavy page widens it. Either way, WebP comes out ahead.

A worked example

Say you maintain a documentation site with 80 PDF white papers, and you want a preview image for each one — the first page rendered as an image, embedded above the download button. Page weight on your docs site matters; Lighthouse currently flags you for image bytes.

At 150 DPI / 90% quality / WebP: each preview is around 220 KB. 80 of them is roughly 18 MB total across the site.

At 150 DPI / 75% quality / WebP: each preview is around 130 KB. 80 of them is roughly 10 MB. Visually indistinguishable from 90% at normal viewing distance — go ahead.

The same previews as JPG at 80% quality would weigh roughly 250 KB each — 20 MB total, or twice the WebP bundle. As PNG (lossless), each would weigh around 600 KB — 48 MB total. Across 80 images on a documentation site, that's the difference between Lighthouse green and Lighthouse yellow. Across thousands of images on a product catalog, it's the difference between sub-second loads and visible delay.

And every byte saved on every visit is a byte your CDN doesn't have to ship. The compounding case for WebP is real, but it shows up in aggregate, not in a single side-by-side test.

WebP, JPG, or PNG — picking the right one

Three formats can come out of a PDF page render. The right choice depends almost entirely on where the image is going.

If you're not sure: WebP for web destinations, JPG for sharing, PDF to PNG for everything else.

Render to image is not the same as extract images

This trips up roughly half the people who land on a PDF-to-image page, so it's worth making the distinction explicit.

Render each page as an image (what this tool does): the whole visible page — text, shapes, embedded photos, everything — is drawn flat onto a canvas at your chosen DPI. One WebP per page. The text inside the rendered image is now pixels; you can't select it.

Extract the embedded images from a PDF (different tool): pulls out the photos that were placed inside the PDF, at their original resolution, as individual files. Text and vector content are ignored. A page with two product photos gives you two image files — not one image of the page.

If you need the embedded photos back, use Extract PDF Images. If you need each page as a flat image you can drop into a webpage, you're in the right place.

What about transparency

WebP does support an alpha channel — that's one of its advantages over JPG. In principle the rendered WebPs could preserve PDF transparency. In practice this tool paints a white background before rendering, because virtually no real-world PDFs have transparency in places where you'd want it preserved in the output, and the few that do (design exports, branded logos on transparent canvases) are better handled by PDF to PNG for predictability.

If transparency support becomes a common request we'll add a toggle. For now: WebP output here is opaque, with white wherever the source PDF was transparent. If you need a transparent PNG, use the PNG converter.

Edge cases worth knowing

A few things to keep in mind.

Older browsers and email clients. WebP is universal in modern browsers but not in everything. Outlook on Windows used to balk; recent versions handle it. Some image viewers on older operating systems (pre-2020 macOS, older Linux distros) need a plugin. If you'll email the images directly to someone whose setup you don't control, JPG is the safer pick — that's why we ship PDF to JPG alongside this tool.

Scanned PDFs. A scanned PDF is already a bitmap. We render each page at the DPI you pick, but the output can't be sharper than the source scan. If the original scan is 100 DPI, asking for 300 DPI output just upscales — same detail, more bytes. Match the DPI to the source for the cleanest, smallest result.

Encrypted PDFs. Won't open. Unlock in Acrobat or Preview first.

Filled-in forms. Usually render fine. Some Adobe Acrobat digital signature widgets can render as outlines or with gaps. If a page looks wrong, flatten the form first with PDF Flatten Form and re-convert.

Mixed page sizes. A PDF with a wide cover, A4 body pages, and a fold-out will give you WebPs of different pixel sizes. Filenames are zero-padded by page number, so sort order still matches reading order.

Big PDFs at high DPI. WebP encoding is fast, but rendering is the bottleneck. 200 pages at 300 DPI can use 2-3 GB of browser memory. For very large documents, split the PDF first with Split PDF and convert each chunk separately.

Why in-browser matters

The big online PDF converters all upload your PDF to a server, render it there, and stream the WebPs back. iLovePDF, SmallPDF, PDF24, Sejda, Convertio, CloudConvert — every one of them is built that way. For a marketing PDF it doesn't matter. For a contract draft, a personal medical record, a financial statement, a sensitive internal document, it matters a lot.

Browser-side rendering exists because Mozilla wrote PDF.js so Firefox could render PDFs natively, then open-sourced it. Every PDF you've ever opened in Firefox was rendered with the same library we use here. We aren't being clever — we're just refusing to throw the privacy property away by needlessly routing files through a server. The 10% Pledge — 10% of revenue to charity, off the top — depends on actually delivering the tool, not selling subscriptions to bypass artificial limits on free software.

Related PDF and image tools

The PDF to WebP Converter sits alongside a stack of related tools, all of them browser-side:

• WebP to PDF — the reverse. Bundle a folder of WebPs into a single PDF.
• PDF to PNG — same job, lossless PNG output. Pick this when transparency must survive or text sharpness is paramount.
• PDF to JPG — same job, JPG output. Pick this when the destination might not handle WebP.
• Extract PDF Images — pulls the original embedded images out at full resolution. Different job from rendering pages.
• Compress PDF — shrinks a PDF without converting it to images at all.
• Split PDF — slice big PDFs before converting.
• Image Format Converter — go between PNG, JPG, and WebP after conversion if you change your mind.
• Image Compressor — shrink the WebPs further if the file size still isn't where you need it.

Frequently asked questions

When should I use WebP instead of JPG?

When the output is for web or web-app embedding and you care about page weight. WebP files are typically 25-35% smaller than equivalent JPG at the same visual quality, which compounds across many images. Don't use WebP if you'll email the images to someone on an older OS (pre-2020 macOS, older Windows) — they may not have native WebP viewer support. JPG is the safer default for sharing; WebP is the smarter default for web embedding.

Does WebP support transparency?

WebP supports an alpha channel similar to PNG. This tool paints a white background before rendering — since most PDF pages don't have transparency, that keeps output predictable. The WebPs here won't carry transparency. If you need transparency preserved, use PDF to PNG.

Will the output work in every browser?

Every browser shipped since 2020 supports WebP natively: Chrome (since 2010), Firefox (2019), Edge (2018), Safari (2020), Opera. For older browser support (IE11, some Android stock browsers, very old corporate environments), use PDF to JPG instead.

Is my PDF really not uploaded?

Correct. Rendering runs in your browser via PDF.js; WebP encoding uses the browser's native canvas.toBlob. Zero outbound requests during convert. Check your browser's network tab.

I want the photos that are inside the PDF, not pictures of each page. What do I use?

That's a different tool. This one renders each page as one flat image. To pull out embedded photos at their original resolution as separate files, use Extract PDF Images.

What's the max file size and page count?

100 MB per PDF, 200 pages. WebP encoding is fast — 100 pages at 150 DPI / 75% quality converts in around 30-45 seconds on a modern laptop. For bigger documents, split first with Split PDF.

Why are some pages slightly different sizes?

Each output WebP is sized to its source page at the chosen DPI. If your PDF has pages of different sizes (cover plus spreads, or A4 mixed with Letter), the WebPs will reflect those sizes. Filenames include a zero-padded page index so downloads still sort in reading order.

Does this work on phones?

Yes. PDF.js runs the same on mobile browsers, and all modern mobile browsers support WebP. For long PDFs at 300 DPI, memory limits may bite on older phones — stick to 150 DPI at 75% quality or lower for big jobs on mobile.

Can I download all pages as a ZIP?

Not yet. The Download all button triggers individual downloads in sequence, about 150 ms apart. For 100+ pages, download in batches. ZIP support is on the roadmap.