Drop your WebP files into the processing zone below and get a document back that opens anywhere. A PDF cannot hold WebP data at all, so this conversion is a rewrite rather than a repackaging, and the engine reads your file header to pick the least damaging way to do it. A lossless WebP, or one carrying transparency, is rewritten as a PNG and loses nothing. An ordinary photographic WebP goes to JPEG. Nothing is uploaded: the work 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 image to pdf converter above is working right now. The notes below explain why WebP is three different formats wearing one file extension, how the engine tells them apart before it touches a single pixel, what happens to transparency and to animated frames, and why the PDF that comes out is usually larger than the files that went in.
Two minutes, and nothing to install. No account is needed to try it. This pdf tools utility runs inside the page you are reading, so the decoding and the rewriting both happen on your hardware rather than on a server somewhere else.
Click the drop zone above or drop your WebP files onto the page. Headers are read as each file lands. The extension is ignored. The card tells you whether that image is lossy, lossless, carrying transparency or animated, and which rewrite route it takes because of that.
The order of the cards on screen is the order of the pages you get. Move a card to change where its page lands. The sorter reads the digits in a filename as a number, so image 2 goes ahead of image 10 rather than after it.
Pick A4 or US Letter and every image is scaled to fit inside the sheet. Pick Fit to image and the page is built to the physical size the image implies instead. Then set your margins.
Press Convert to PDF. The rendering happens on your machine. Open the result and look at one page at 100 percent zoom before you commit to a long batch. A single generation of re-encoding can soften fine typography when the source was already compressed hard.
A PDF carries images through a fixed set of compression filters and no others. DCTDecode carries JPEG data. FlateDecode carries deflate-compressed pixels, which is what PNG uses. JPXDecode carries JPEG 2000. There is no filter for WebP data anywhere in the specification, and there is never going to be one.
That has a hard consequence. A JPG or a PNG goes into a pdf document without ever being decoded, because the container already understands those bytes. WebP cannot. It has to be decoded to raw pixels in memory and then encoded again into something the specification accepts. Any pdf software advertising a lossless passthrough for WebP is describing a thing that cannot exist.
What a good converter does instead is keep that unavoidable rewrite as cheap as it can be, by reading the file header and choosing the destination format to suit whatever is actually inside.
A .webp file is a RIFF container. The four character chunk tag sitting at byte 12 states which coding is inside, and the engine reads that tag before it does anything else at all:
| Header Chunk | What Is Inside | Our Route |
|---|---|---|
| VP8 | Lossy. An intra-only VP8 video keyframe doing duty as a still image. | Rewritten as JPEG at quality 0.92. |
| VP8L | Lossless. A dedicated still-image coder with no video heritage. | Rewritten as PNG, so no image data is lost. |
| VP8X | Extended container. May carry transparency, a color profile or animation. | PNG when the alpha flag is set, JPEG when it is not. |
That distinction matters more than it sounds. Somebody who saves an interface mockup or a schematic as a lossless WebP made a deliberate decision to protect hard edges. Pushing that file through a JPEG encoder would undo the decision and put ringing around every letter. Reading the chunk tag is what keeps a lossless input a lossless output.
Trust the file card, not the file name. The engine reads the raw binary header and ignores whatever MIME type your operating system reports. If a file named photo.webp turns out to be a PNG that somebody renamed, it is handled as a PNG and takes the lossless route.
WebP carries an 8-bit alpha channel on both its lossy and its lossless paths. PDF handles per-pixel opacity differently, through a soft mask: a second greyscale image attached to the first, where each value sets the opacity of the matching pixel. The two happen to be mathematically equivalent. A WebP alpha channel maps onto a PDF soft mask exactly, with nothing lost in the translation.
A WebP carrying transparency is routed to the PNG rewrite whether the source was lossy or lossless, purely because that route is the one that keeps the alpha channel intact. A logo keeps its feathered drop shadow and composites correctly over a colored layout. The JPEG route would fill those pixels with white. That is why the header check happens first.
A VP8X container often holds animation frames. There is no way around what happens next. A PDF page is static, so an animated WebP dropped into this tool produces one still image of the first frame and nothing else. That limit belongs to the destination format. No converter can work around it, and any that claims to is lying about the file it hands back.
The engine flags the VP8X animation bit on the card before you convert. The loss is never something you find out about afterwards. If you need every frame, export the animation to a numbered image sequence first, then drop that whole stack in to get a page-by-page flipbook out of the pdf maker.
Google built WebP to make images load faster on web pages, and at that job it is genuinely very good. The trouble starts the moment you move one of those files out of a browser and into ordinary office work.
Converting to a pdf file is an extraction. The image data comes out of a container that only recent browsers read reliably and goes into one that every machine in the building opens, and the small amount of quality the rewrite costs buys you a file the recipient can actually use. That is usually the right trade. Make it deliberately rather than by accident.
A PDF is a delivery format, and the conversion runs one way. Keep your master WebP files after converting. The quality the rewrite spends cannot be refunded out of the PDF later, and converting the PDF back to WebP only spends it a second time.
A handful of website assets converts in seconds and costs the free engine nothing. Fifty high resolution WebP files is a different story. Every one of them has to be fully decoded into an uncompressed bitmap before it can be encoded again, and those bitmaps all sit in the same browser tab at the same time, which is what eventually exhausts the memory and takes the tab down with it.
Anonymous visitors get one operation every 12 hours, free accounts get two, and both cap a batch at 20 files or 100 MB. CartHacker Premium removes the operation counter and lifts the batch ceiling to 100 files and 500 MB. The processing model does not change at either tier. Your files still never leave the machine.
The usual shape of a pdf converter online free is an upload script that copies your files to a server, a backend library that processes them, and a privacy policy asking you to believe the copies get deleted afterwards. That belief is doing a lot of work. It has to survive a compromised database, a retention schedule nobody reviews, and an acquisition.
This engine has no ingestion endpoint to upload to. The JavaScript in your tab uses the browser File API to decode, scale and assemble the document on your own CPU. Your files stay in local memory from start to finish, so there is no remote copy to intercept, to scrape for training data, or to leave sitting in a storage bucket somebody forgot about.
This is checkable rather than promised. Load the page, take the machine off the network, and drop a batch into the queue. The conversion runs to completion, because there is nothing on the other end of a wire that it needs.
It costs one re-encoding generation, and there is no way around that, because the PDF specification has no filter that can carry WebP data. The engine limits the damage by choosing the destination format from the file header. A lossless WebP, and any WebP carrying transparency, is rewritten as PNG and loses nothing at all. An ordinary photographic WebP goes to JPEG at quality 0.92, where a single generation is effectively invisible at document viewing sizes.
Because PDF works from a closed set of image compression filters that every reader has to implement, such as DCTDecode for JPEG and FlateDecode for PNG. WebP is not on that list and never has been. If we wrote raw WebP data into the container, a PDF reader would hit a filter name it does not recognize and fail to render the page at all.
Yes. When the alpha flag is set in the WebP header, the engine routes that file to the PNG rewrite rather than the JPEG one, specifically to keep the transparency. It is then written into the document as a native PDF soft mask. We do not flatten transparent graphics onto a white box the way most converters do.
You can, but you get the first frame only. A PDF page is static and has no timeline to play the rest on. The interface flags the animation bit from the VP8X header on the file card, so you know before you convert rather than after. To keep every frame, export the animation as a numbered image sequence and drop that stack in instead.
No. This online pdf editor runs inside your web browser on your own CPU, and there is no upload endpoint in the code for files to travel to. Your images are never transmitted anywhere. That makes it a sensible choice for unreleased product shots, internal diagrams and anything covered by an NDA.
Drop the whole batch into the zone and leave Merge all images into one PDF switched on. The engine puts one image on each page, following the order of the cards on screen. Drag the cards to change that order before you convert.
Yes, in terms of pixel values. The file is decoded and rewritten as a PNG, which is also lossless, so every pixel in the finished PDF matches the pixel in your source. The file size does go up, because PNG compression is considerably less efficient than the VP8L coder that WebP uses.
WebP compresses far harder than any format a PDF can carry. Going from VP8L to PNG, or from VP8 to JPEG, means giving that efficiency back, and a lossless WebP rewritten as a PNG often doubles in size. Reducing the pixel dimensions of the images before you convert is the effective lever, not compressing the PDF afterwards.
No. Only the pixel data and the rendering instructions reach the PDF. The extended VP8X metadata chunks that can hold GPS coordinates, camera identifiers and color profiles are dropped during the rewrite, because the new image is built from decoded pixels and carries nothing else along with it.
Anonymous visitors get one operation every 12 hours and free accounts get two, with both capped at 20 files or 100 MB per batch, because a browser holding that many uncompressed bitmaps runs out of memory. CartHacker Premium removes the operation counter and raises the batch ceiling to 100 files and 500 MB.
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.