Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
Converting WebP to PDF wraps the image in a document for the form, report or printer that will not take it on its own. Transparency survives and nothing is uploaded — but expect the PDF to be several times larger than the WebP, because a PDF cannot store WebP data and has to keep the picture as a PNG instead.
Up to 100 files at once. Mixed formats are fine.
They convert one after another and download together as a ZIP.
WebP to PDF
WebP files end up needing to be PDFs for the same administrative reasons everything else does. A screenshot for a support ticket, a chart pulled off a dashboard, a product image for a supplier form, an image saved from a website that now has to be filed. The picture is right; the wrapper is wrong; and the system at the other end has an opinion about wrappers.
A PDF can carry JPEG data directly, so a JPEG goes into the document completely untouched — nothing decoded, nothing re-encoded, the same bytes in the file. A PNG does not have that privilege either: PDF has no PNG filter, so it is decoded and its pixels are deflated again. PDF has no idea what WebP is at all.
So this conversion decodes your image and stores the pixels in the document compressed losslessly, the way a PNG source is stored. No pixel value changes and nothing is compressed lossily, but the picture has been through a decode, which is one step more than the JPG route. On any real image you will not see it.
WebP is very good at compression and PNG is not, so the picture inside the PDF takes several times the space it did as a WebP. A 200 KB image becoming a 2 MB PDF is entirely normal and is not a sign that something went wrong.
If the size matters more than anything else — an upload limit, an email attachment — converting the WebP to a JPG first and then that to a PDF gives a much smaller document, at the cost of one extra lossy step and any transparency the image had.
This sets it apart from converting to JPG. PDF has a real understanding of alpha, so a cut-out logo or an icon with no background keeps it. Printed, that means it appears on white paper; placed into another document, it blends with whatever is behind it. If you wanted a solid background, add it before converting rather than hoping the PDF will supply one.
Fit-to-image gives you a page exactly the shape of the picture, with no border and nothing scaled, which is right for anything being uploaded. A4 or Letter centres it on a real sheet with a margin, which is right for anything being printed. The image is scaled down to fit when it is too large and never scaled up.
Everything happens in your browser: the WebP decoder and the PDF writer both run on your machine, and the file is not uploaded anywhere.
Most WebP files people convert were saved from a web page, which means they were sized for a web page — often eight hundred pixels wide, sometimes less. That is fine on screen and thin on paper: printed at A4 it works out at roughly seventy dots per inch, which looks soft.
Nothing in a conversion can add detail that was never downloaded. If the printed result matters, go back to the source and look for the full-size image before converting the version your browser happened to cache.
The image goes in as an image, so anything written in it stays a picture of writing: not selectable, not searchable, invisible to a screen reader. For a saved diagram or a chart that is usually irrelevant, and for a saved page of text it is the thing that matters most.
What you do gain is a fixed page at a fixed size that opens in a reader rather than in whatever the receiving machine decided handles images. That predictability is normally the entire reason the other end asked for a PDF.
| WebP | ||
|---|---|---|
| Full name | WebP Image | Portable Document Format |
| File extension | .webp | |
| Media type | image/webp | application/pdf |
| Compression | Either, depending on the setting | Either, depending on the setting |
| First published | 2010 | 1993 |
| Published by | Adobe | |
| Specification | RFC 9649 | ISO 32000-2 |
| Licensing | Open standard | Open standard |
| Standing today | Current | Current |
| Bit depth | 8 | — |
| Colour it can describe | RGB, YCbCr | RGB, CMYK, greyscale |
| Largest image | 16,383 px per side | — |
| Opens in a browser | Every browser | Every browser |
| Considered instead | AVIF, JPG, PNG | DOCX, HTML |
PDF has nowhere to put the EXIF block — camera, lens, shutter speed and ISO and the embedded ICC colour profile, so those go no further than the WebP. Worth checking before the original is deleted, and worth knowing if the point was to strip it.
Nothing is discarded. WebP and PDF both store their content losslessly, so the conversion is a change of packaging rather than a change of quality, and it can be repeated without accumulating damage.
Transparency survives. Both WebP and PDF store an alpha channel, so a cut-out stays cut out and nothing is filled in behind it.
PDF supports layers. A WebP arrives already flattened, so the result has one layer — the structure has to be rebuilt by hand if it is needed.
The usual programs do not overlap: WebP opens in Adobe Photoshop, GIMP and Squoosh, PDF in Adobe Acrobat, Preview and LibreOffice Draw — so whoever receives the result needs something from the second list.
WebP is Google's format, published in 2010. It records 8 bits per channel.
PDF comes from Adobe and dates from 1993, specified as ISO 32000-2. Adobe Acrobat, Preview and LibreOffice Draw all read it.
PDF was published in 1993 and WebP in 2010. The older one is generally the safer file to hand to somebody; the newer one usually does the job in fewer bytes.
No. This conversion runs entirely inside your browser, so the file never leaves your device. You can confirm it yourself: open the network tab of your browser's developer tools and convert something. You will see the page load, plus the analytics and advertising the site is paid for with — and nothing carrying your file. The engine behind this particular pair is pdf-lib, a PDF writer that runs entirely in JavaScript; your browser fetches it once and caches it.
No pixel changes, but this is the one image-to-PDF conversion that is not a pass-through. A PDF can hold JPEG data directly and has no filter for WebP, so the picture is decoded and its pixels are deflated into the document losslessly instead. Nothing is compressed lossily; it is simply not the untouched copy that JPG to PDF is.
Because the image inside it is stored as PNG rather than WebP, and WebP compresses far better. A 200 KB WebP can easily become a 2 MB PDF. That is the format doing what it does, not a fault.
Convert the WebP to a JPG first, then that JPG to a PDF. JPEG data goes into a PDF untouched, so the document ends up a fraction of the size — at the cost of one extra lossy step and any transparency the image had.
Yes. PDF understands transparency, so a cut-out image stays cut out — it will appear over white when printed and over whatever is behind it when placed into another document.
Not yet. Each file becomes its own PDF; merging is a PDF tool rather than a conversion and is on the list.
The claims this page makes about WebP and PDF are checkable, and these are the documents that settle them.