Converting WebP to PDF

Where WEBP came from, and why it is like this

WebP is a web-delivery format. PDF is a document format. The gap between those two sentences is the entire reason this conversion exists, and it has nothing to do with image quality.

WebP was designed to be served by a web server and decoded by a browser, and it is very good at that. It was never designed to be attached to an email, printed, filed, or handed to a system that expects a document — and outside browsers its support is still patchy enough that sending someone a .webp is a reliable way to get a confused reply. PDF is the opposite: an old, boring, universally readable container that every operating system, printer, mail client and upload form already understands.

So this conversion is a translation between two different worlds rather than between two image codecs. What you are really doing is taking something the web produced and making it acceptable to everything that is not the web.

Is this conversion lossy?

A little, and for a slightly unexpected reason. The WebP is decoded to pixels and re-encoded on the way into the PDF, so if the source was a lossy WebP this is a second lossy generation. At normal quality the difference is invisible; on an image that was already aggressively compressed for a web page — which is what most WebP files are, because that is why anyone chose WebP — there is not much detail left to lose, and not much to protect either.

File size usually goes up, often considerably. WebP's whole purpose is to be small, and a PDF wrapper around a re-encoded copy of it discards most of that advantage. A folder of small WebP images can become a PDF many times their combined size.

What happens to metadata, transparency and colour

Transparency is flattened. WebP supports an alpha channel and PDF technically does too, but the canvas path used here composites the image onto a background before embedding it. A WebP logo with a transparent background lands on solid colour. If the transparency is doing design work, composite it deliberately in an editor first so you choose the colour rather than the converter choosing it for you.

Animation is lost. An animated WebP becomes a single still frame, because a PDF page holds one image and a canvas holds one frame. There is no browser-native path from animated WebP to a multi-page PDF of its frames.

Metadata does not carry. WebP can hold EXIF and an ICC profile; the canvas round-trip drops both, and the resulting PDF gets fresh, empty document metadata. You can set that afterwards with the metadata editor.

Resolution is whatever the WebP had. Web images are usually sized for a screen, not for paper, so a WebP saved from a page will often look soft when printed. Nothing about the conversion can add detail that was never downloaded.

Why people actually need this

Someone saved an image from a website and now has to submit it somewhere that takes PDF. That is the whole story, and it comes up most often with proof of something: a booking confirmation, a receipt shown only in a browser, a screenshot of an order page, a certificate rendered as a web image. The system on the other end wants a document, and it will not take .webp.

The second situation is grouping. Several images saved from a site need to arrive as one file in a fixed order — a set of product shots, pages of an online statement, a sequence of screenshots documenting a problem. PDF is the only container that holds them in order and that everyone can open.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

And the ceilings measured for Image to PDF, the tool that performs it, on the hardware described on the limits page:

Not tested

The page also refuses files above 20 MB before it starts, which is a guard written into the tool rather than something the browser imposes. Why those are different.

When something else is the better answer

If the destination accepts images at all, converting to JPG or PNG is usually simpler and keeps the file much smaller. Check the accepted-formats list before reaching for PDF — plenty of forms take JPEG and are only listed as "image".

If the WebP has transparency you need to keep, PDF is the wrong destination here; convert to PNG instead, which preserves the alpha channel.

If the image is a screenshot of text and the recipient will need to search it, a picture in a PDF is not a document. Run OCR and send the text alongside it.

If the result needs to be smaller, compress the image before converting rather than compressing the finished PDF — per the measured limits, compressing a PDF rasterises every page, which is a much heavier operation for the same outcome.