WebP to PDF converter

Why WebP has to be decoded first

PDF defines image objects it can carry directly: JPEG (DCTDecode), deflate-compressed raw samples (FlateDecode) and a few legacy variants. WebP is not one of them, so a WebP file cannot simply be pasted into a PDF the way a JPEG can. The browser decodes the WebP onto a canvas, the engine reads the resulting RGBA buffer, splits colour from alpha, and hands both to pdf-lib.

The important part is what happens after decoding: the samples are stored as an 8-bit DeviceRGB image with a deflate filter, which is lossless. No JPEG re-encode is introduced, so the soft edges and gradients that made WebP a good choice stay intact in the PDF.

• WebP is decoded by the browser, then embedded as a lossless PNG image object
• Alpha becomes a separate PDF SMask rather than being flattened onto white
• One input WebP produces one PDF with exactly one page
• Output keeps your original base name with a .pdf extension

Lossy and lossless WebP behave the same way

Whether your WebP was saved lossy or lossless, the decode step produces the same pixel grid the browser would display, and that grid is what lands in the PDF. The PDF cannot recover detail a lossy WebP already discarded — it faithfully reproduces what the WebP shows, nothing more.

Animated WebP is a real limitation: the image decoder resolves the first frame, so an animation becomes a single still page. There is no frame sequence in the output.

Transparency in a PDF viewer

WebP supports alpha, and PDF supports alpha through a mask object. The engine writes the RGB samples and the alpha samples separately, so transparent and semi-transparent pixels remain transparent when the PDF is opened. There is no background fill behind the image: on a viewer with a dark theme, transparent areas read as dark.

That makes this route suitable for cut-out logos, overlays and icons exported as WebP that must keep their edges in a document. If you need the opposite — transparency flattened onto a solid colour — convert WebP to JPG first, which fills the alpha with a background you choose.

• Full and partial alpha are carried as a PDF SMask
• No background colour is painted behind the image
• Flattened backgrounds require a JPG route instead
• Soft edges from a lossy WebP stay soft, because the PDF step adds no compression

Why the canvas step is unavoidable

PDF image objects accept JPEG samples, deflate-compressed raw samples and a couple of legacy encodings. WebP is not one of them, so the browser has to decode the file before anything can be written. The canvas is the decode target: the RGBA buffer it produces is read back and split into colour and alpha arrays.

That decode is the same one a browser performs when displaying the WebP, so the PDF reproduces what the image looks like on screen. A lossy WebP with soft gradient edges stays soft in the PDF; the canvas step does not sharpen or resample anything.

Opaque versus alpha WebP

An opaque WebP produces an image object with no mask, and the page behind it stays white. A WebP with alpha produces an image object plus a separate SMask, and transparent areas read as whatever the viewer's background is. Check a transparent asset against both a light and a dark viewer background before shipping it, because the mask itself does not choose a colour.

If the destination needs a solid background — a printed sheet, for example — flatten first with the WebP to JPG route, which paints White, Black or Paper underneath the image, then wrap that JPG in a PDF.

Page size and file size

The default preset, Fit, makes the page measure the image's pixel dimensions in points and draws the image across the whole page. A 1280×720 WebP becomes a 1280×720 pt page. Choose A4 for a printable sheet: 595×842 pt, image scaled inside 24 pt margins and centred, aspect ratio preserved.

On size, be realistic. WebP is usually the smaller file; the PDF re-stores the decoded pixels as raw samples plus a mask and then deflates them, so the PDF is often larger than the WebP it came from. Convert to PDF when the container is the requirement, not when you want a smaller image.

• Fit: page equals image dimensions, image fills the page
• A4: 595×842 pt page, image scaled inside 24 pt margins
• Expect a PDF comparable to or larger than the source WebP
• Aspect ratio is preserved in both presets

Limits and local execution

The engine requires a decodable image with real dimensions, rejects an empty file and a file larger than 20 MB, and refuses images above about 40 megapixels because decoding and saving both consume browser memory. Colour profiles and text metadata are not transferred into the PDF.

Everything runs locally: the file is read from your disk, decoded on a canvas, assembled by pdf-lib and saved as a Blob in this tab. No upload happens and nothing is stored after you close the page. The vendor pdf-lib bundle is fetched from this site's own assets only when a PDF conversion is requested, and aborting a batch stops the run cleanly.

• One file per run (the picker converts a single image), each up to 20 MB
• Animated WebP becomes a single still page
• Metadata and colour profiles are not preserved
• Runs entirely in the browser; abort stops the batch

Beta status

This route is beta. It is tested against browser-generated WebP fixtures for the %PDF header, page count, page dimensions, the presence of an image object and the presence of a mask, but real-world WebP files vary — lossy versus lossless, alpha versus opaque, animated versus still. Open the first PDF in your own viewer before converting a batch, especially for assets with transparency.

• Verified on generated fixtures for structure and alpha handling
• Real-world WebP variants should be checked in your viewer
• No multi-page merging, no rotation, no DPI control

Questions