WebP to JPG — Batch-Convert WebP Images to Universal JPG Online for Print, Email and Legacy Systems, Processed Locally
WebP to JPG is about compatibility: WebP is small and sharp on a web page, yet it runs into a wall as soon as it leaves the browser. Layout software at a print shop, an older Office build, application systems that accept only JPG, some mail clients and legacy image viewers often throw an error or show a blank box when they meet a .webp file. This page decodes the WebP fully in your browser and re-encodes it as JPG with a quality slider you control: higher values keep more detail and produce larger files, and around zero point eight five is usually a good balance. JPG has no alpha channel, so for icons or cut-outs with transparent areas you can pick a fill colour — it starts out white — to avoid dark fringes. Drag in several files at once, watch each one’s status and size in the batch list, step through the preview with Previous and Next to compare side by side, then download one image or pack the whole batch into a ZIP. The target-format dropdown switches to PNG at any time, and already-decoded images re-export automatically without being imported again. Decoding uses the browser’s own capability, nothing is uploaded and the page still works offline; the result is a clean new file that does not automatically carry over EXIF shooting time, camera model or location. An animated WebP contributes only its first frame, and the batch list also lets you retry a failed file on its own or download just a few images.
Import images
Target format
Both formats reuse the same decoded pixels, so switching re-exports automatically — no need to import again.
JPG is the most compatible and usually the smallest. Ideal for messaging, email, printing and older systems; it cannot store transparency.
Higher values keep more detail and produce larger files. Around 0.85 suits photos; push it higher for screenshots.
JPG has no alpha channel, so transparent and semi-transparent areas are filled with this colour. It starts out white, and you can change it to any colour.
A few WebP files carry an orientation flag or come from a portrait shot and decode sideways. Correct them here.
Leave it empty to keep the original name; the extension is replaced with the output format.
Preview and export
Batch list
0 / 0 DoneNo images imported yet.
How to use
- Drag .webp images into the import area, or click Choose images to select several at once; Ctrl+V pastes a screenshot too. The tool identifies the real format from the file header, so a wrong extension does not matter.
- Keep the target format on JPG and start with quality around zero point eight five to see the file size, then nudge it either way: push a photo too hard and the sky bands; for text screenshots, watch whether strokes go soft.
- If the source has transparent areas, choose a background colour in Transparency fill; a few WebP files carry an orientation flag and decode sideways, so correct those with Extra rotation.
- Use Previous and Next in the preview to check both panes image by image, then download the current one, download individual rows from the batch list, or pack everything into a ZIP. Changing the dropdown re-exports the already-decoded images automatically.
Frequently asked questions
Why will a WebP image not open in some programs?
WebP only appeared in 2010, and browser support took nearly ten years to become complete, while plenty of desktop programs, older Office builds, print layout systems, content management back ends and upload forms still read only JPG and PNG. The file is not damaged; the program on the other side simply has no WebP decoder. A JPG depends on nothing installed on the system, opens on any computer you copy it to, and is the least troublesome thing to hand to a print shop or upload to a form.
Does converting to JPG lose quality a second time?
It does, though usually invisibly. A lossy WebP has already been compressed once, and decoding to pixels before re-encoding with a JPG quantisation table is a second lossy pass; sky gradients and high-contrast edges are the likeliest places to show faint banding or ringing. Above quality zero point eight five it is essentially imperceptible at normal viewing sizes, and if you want later edits to cause no further loss at all, use the PNG page, which stores the decoded pixels losslessly — while understanding that it cannot bring back what the first compression discarded.
What happens to a transparent background?
JPG has no alpha channel, so transparent and semi-transparent areas must be composited onto a solid colour — it starts out white, and you can change it to any colour in Transparency fill. For a cut-out product shot or a rounded logo, pick the colour of the page it will sit on, otherwise a white halo appears on a dark background. Switch to PNG if you need to keep transparency, since it supports a full alpha channel.
Will an animated WebP still animate after conversion?
No. When a browser hands an animated WebP to canvas it supplies only the first frame, and a re-encoded JPG holds a single still frame, so the result is one static image. If the motion matters, keep the original WebP or use a dedicated animation tool; this page exists to bring the asset back to the most universally accepted still format.
Are my images uploaded to a server?
No. Decoding, orientation correction, quality adjustment and encoding all happen in the browser, WebP pixels are unpacked by the browser itself, image data never leaves your device and the page has no upload endpoint. Once it has loaded you can even keep converting offline. The flip side is that the list is gone when you close the tab, so keep your own backup of important originals; the output is a brand-new file and no EXIF shooting data is carried over.
What is it
The difference between WebP and JPG is not which looks sharper, but what each was designed for. WebP is an image format Google built on VP8 video key frames, packing data into a RIFF container and offering lossy coding, a separate lossless mode, an alpha channel and animation in one specification; its lossy mode predicts a block of pixels from its neighbours and records only the residual, which is why it is often some thirty percent smaller than a JPG for the same perceived quality. JPG is an older standard settled in 1992: it splits the picture into eight-by-eight blocks, applies the discrete cosine transform and discards high-frequency coefficients through a quantisation table, and commonly halves colour resolution with four-two-zero chroma subsampling. Converting to JPG means the browser first unpacks the WebP into full pixels and then runs blocking, transform and quantisation once more, an irreversible second round of loss: detail the source already discarded never returns, and sky gradients or high-contrast edges are the first to show banding or ringing. The quality slider controls that quantisation table, and setting it to one keeps the most detail but noticeably enlarges the file. A WebP with alpha is composited onto the chosen background first, because JPG has no transparency dimension at all; EXIF, ICC and animation frames in the container do not come along either, and a multi-frame WebP contributes only its first frame. The tool identifies the real format from the file header, so a wrong extension does not matter.
Origin & history
Lay the timeline out and two formats nearly twenty years apart meet on the same machine. JPG comes first: in 1992 the JPEG standard was published jointly by ISO and ITU, using the discrete cosine transform and quantisation tables to squeeze a photograph into a few tens of KB, and around 1994 JFIF spread until virtually every program could read it; the core barely changed over the next three decades, at the cost of eight-bit depth, no transparency and visible blocking at high compression. The other strand begins in September 2010: Google had acquired video coding company On2 Technologies the year before, taking ownership of VP8, and released WebP based on its intra coding, using a RIFF container to hold the image data. The first version was lossy only; 2011 added an alpha extension, and around 2012 came separate lossless coding, metadata and animation, while libwebp was adopted by Chromium, Android and a great many server-side toolchains. Then came the long rollout: Chrome supported it early, Firefox only caught up in 2019, and Safari completed the set in 2020, so picture elements and server-side content negotiation by request header were effectively mandatory, with two assets to maintain per page. The interesting twist is that once WebP spread, the trouble moved from inside the web to outside it: design software, older Office builds, print workflows, content management systems and upload forms long recognised only JPG or PNG, and the growing pile of .webp files in site directories could barely take a step beyond the browser. The real solution needed no new algorithm: canvas toBlob had long accepted image/jpeg with a quality argument, so the encoding side was never the obstacle, and once browsers could unpack WebP pixels natively, local decoding plus local re-encoding became the most dependable combination — one that does not even need an upload endpoint. Later AVIF pushed compression further with AV1 intra coding, and JPEG XL made its own round through standardisation, yet the more new formats appear, the less this need to bring assets back to a universal format goes away. A single click today appears to save only an upload, but what it really does is return a computation that always belonged on the local machine to the local machine.
Related keywords
Feedback
Found a problem with a tool or have a suggestion? Email us — we read every message.
