WebP to JPG Converter

Guide: this page documents the one conversion plan it runs, WebP into JPEG. For the general rule — which output formats can hold transparency, which cannot, and why the background colour is asked for before anything is encoded — read Transparency and flattening, or browse all the guides.

What the detector sees in a .webp file

Nothing on this page trusts the filename. The first step reads the leading bytes of each file and matches them against the format signatures the methodology lists: a WebP begins RIFF and then reads WEBP — the RIFF…WEBP signature, where the ellipsis stands for bytes the signature check skips. Run on an illustrative header built at build time, the detector returns WebP. The same bytes paired with the name hero.webp produce no mismatch (no), so conversion proceeds without comment. Pair the name hero.webp with bytes that start FF D8 FF instead and the check reports the bytes as JPEG while the extension claims WebP — mismatch: yes. This page accepts WebP sources only, so a file whose bytes are not WebP is not converted under a false label: the row names the format the bytes actually are and, where the site has a converter for that format, links to it.

The detector also decides the animation caveat before any pixel is decoded. An animated WebP declares itself through the VP8X chunk's animation flag or through ANIM chunks, and the check walks the RIFF chunk list to find either. On the illustrative header whose VP8X flags carry only the alpha bit, the animation check returns no; on the header whose flags also carry the animation bit it returns yes. When the answer is yes, the file row says so before the download appears, because canvas decoding keeps one frame and a JPEG cannot hold more than one anyway.

The plan for this pair

Every decision the tool makes is taken by a pure planning function from two inputs — the detected source format and the target — plus the two controls above. Asked to plan WebP into JPEG with the controls at their defaults, it returns the MIME type image/jpeg; flatten onto a background: yes, with the background #ffffff; encode quality 0.92 on the canvas scale, which is 92 on the encoder's whole-number scale and the position the slider starts at; and animation dropping to the first frame: yes. Each flag is a consequence of the capability table for JPEG output — can it carry per-pixel transparency: no; does its encoder take a quality parameter: yes — combined with the fact that WebP is a container that can hold both alpha and animation.

The controls change only two fields. Move the slider to an illustrative position and pick an illustrative dark background — invented settings, not a recommendation — and the plan for the same pair becomes: flatten yes, background #1a1a1a, quality 0.8 (encoder 80), first frame only yes. The flags that come from the format pair do not move; only the values you supplied do. The planner also refuses rather than guesses. Handed a background that is not a hex colour it answers "Enter the background as a hex color like #ffffff."; handed a quality outside its range it answers "Quality must be between 0.05 and 1.". The colour picker and the slider on this page cannot produce either input, but the refusals are there so that nothing downstream ever runs on a half-formed plan.

For contrast, the plan for the same WebP into PNG — the WebP to PNG page — sets flatten to no and carries no quality parameter at all, because PNG output is lossless and holds alpha. Those differences are the whole reason the two pages exist separately.

Flattening, on this page specifically

Flattening means compositing: before the decoded WebP is drawn to the canvas, the canvas is filled with the background colour, and the image is drawn over it. A fully transparent pixel becomes the background colour; a semi-transparent pixel becomes a blend of its own colour and the background in proportion to its alpha; an opaque pixel is unchanged. The result has no alpha channel left for the JPEG encoder to lose. Two consequences follow from the fact that the plan is decided from the format pair rather than from the pixels. First, the composite runs for every WebP on this page, including fully opaque photographs, where it changes nothing. Second, the file row's note about the colour used appears for every file too — it records what the pipeline did, not whether your particular image had transparent pixels. The default is #ffffff; if the image will sit on anything other than white, pick the colour of that surface before converting, because the flattening cannot be undone from the JPEG. The Transparency and flattening guide covers the same decision for every output format the site produces.

The quality parameter — and what the tool cannot know

The slider's value is handed to the plan as the encode quality and from there to the browser's own JPEG encoder through the canvas. There is no vendored codec on this page: the one self-hosted JPEG encoder on the site, MozJPEG, is used by the Compress JPEG lane only, and this page decodes and encodes with the browser's codecs alone. The quality number is the encoder's parameter on its own scale; it is not a percentage of the original's fidelity, and no setting is "correct" in the abstract. A WebP may have been saved by a lossy or a lossless encoder, and the plan does not consult which — planning takes the format, not the file — so the JPEG encode is a lossy pass over already-decoded pixels in either case. The tool has no measure of visual difference. What it measures is bytes and dimensions, and that is what it reports.

The size change on each row is arithmetic on the two true byte counts and nothing else. As arithmetic on invented numbers — these are not predictions for any real file — a 184,320-byte WebP becoming a 236,544-byte JPEG reads "28% larger — keep your original"; the same input becoming 151,552 bytes reads "18% smaller"; becoming 184,262 bytes reads "less than 0.1% smaller". A result that grows is stated in the same breath as one that shrinks, and the site publishes no blanket compression percentage anywhere, because no percentage is true for every image. If you want a file to land under a given size rather than at a given quality, that is the Image Compressor's compress-to-target search, not this page.

What re-encoding strips

Drawing to a canvas and encoding again discards all embedded metadata: EXIF — including GPS location, camera model, and timestamps — colour-profile tags, and text chunks. That is a feature when a converted image is going to be published, because it cannot leak where it was taken, and a caveat when copyright fields or an embedded profile matter, so keep the original. Orientation is the one exception in effect, not in bytes: decoding uses createImageBitmap with imageOrientation: 'from-image', so any rotation recorded in the file is applied to the pixels before the metadata is thrown away. The JPEG comes out upright without carrying an orientation tag.

How the output is verified and named

No download is offered on the encoder's word alone. Once the encoder's bytes come back they go through the same checks a freshly dropped file would: their leading bytes are sniffed with the same detector that read the input, and must identify as JPEG; then the blob is decoded again and its pixel dimensions compared with the canvas that produced it. A browser that quietly produced some other format, or a file that will not decode, or a dimension that disagrees, is reported as an error — never offered as a mislabeled download. The size shown beside the badge is the output blob's true byte count. The filename swaps the extension for the target's canonical one and keeps the stem — on two invented names, product-shot.webp becomes product-shot.jpg, and an upper-case Holiday.WEBP becomes Holiday.jpg — because the comparison is case-insensitive and the output extension is always written the same way.

Common misreadings

"The row says transparent areas were flattened, so my image had transparency." Not necessarily. The note follows the plan's flatten flag, which is set for every WebP → JPEG conversion. It tells you the composite ran and which colour it used.
"Quality 92 means the JPEG keeps 92% of the original." No. It is the encoder's quality parameter on its own scale. The tool makes no measurement of fidelity and claims none.
"The file got bigger, so the conversion failed." No. The conversion succeeded and the row reported the measured result, labelled "larger — keep your original". Whether a JPEG is smaller than the WebP it came from depends on the image and the quality you chose; the tool measures it rather than predicting it.
"My animated WebP converted, so the animation is in the JPG." It is not. The plan's first-frame flag is yes for every WebP source, and the row flags the file when the detector finds the animation flag or an ANIM chunk.
"It ends in .webp, so it is a WebP." Only the bytes decide. The illustrative hero.webp whose bytes begin FF D8 FF is reported as JPEG, not converted as WebP.
"A lossless WebP into JPG is a lossless conversion." No. The target decides: JPEG output is lossy (yes in the capability table), whatever the source was.

Limits on this page

This site's input limits, stated here as the methodology lists them, are 50 megapixels, 100 MB per file, and 40 files or 300 MB per selection; they bound a selection before any plan is made, so a browser tab is never asked to hold more than it can. Files are processed one after another within a selection. Dimensions are not changed here — the JPEG has exactly the pixel size of the decoded WebP, which the verification step confirms — so an image that also needs to be smaller in pixels should go through the Image Resizer first.

Keep transparency with WebP to PNG. Already have JPGs that are too heavy? The Image Compressor can re-encode them to a target size in KB. Producing WebP rather than consuming it happens over at JPG to WebP. The reasoning behind the flatten flag, across every output format, is in Transparency and flattening; the rest of the guides cover detection, the pipeline, quality parameters, and metadata in the same build-time-computed style.

Frequently asked questions

What happens to transparency when converting WebP to JPG?

JPEG has no alpha channel, so the plan for this pair sets its flatten flag and the decoded pixels are composited onto the background colour you choose (#ffffff unless you change it) before encoding. The page says so above the controls, before you convert, and the file row repeats the colour that was used.

What does the quality slider actually set?

It sets the quality parameter the plan hands to the browser's JPEG encoder. The slider's starting position matches the planner's default for JPEG output, 92 on the encoder's whole-number scale. The tool does not recommend a setting, because it cannot see what the image is for; it reports the true output byte count for whatever you pick, so you can compare runs with real numbers.

Does converting lossy WebP to JPG lose more quality?

The JPEG target is lossy — the planner's capability table records it as such — so the decoded WebP pixels go through a second lossy encode. The tool measures bytes and dimensions, not visual difference, so it cannot tell you how much that pass changed. Keep the original WebP.

Why JPG instead of PNG?

The two plans differ in the two decisions this guide is about: the PNG plan sets no flatten (no) and takes no quality parameter, while the JPEG plan sets both. If the destination has to hold transparency, PNG is the only one of the two that can, and the WebP to PNG converter is the right page. The tool cannot know the destination, so it states the difference rather than choosing for you.

Is anything uploaded while converting?

No. The whole pipeline — decode, composite, encode, verify — runs in your tab. The site’s security policy blocks requests to other origins, and the methodology page shows how to confirm that in your browser’s network inspector.

Only the first frame of my animated WebP converted — why?

JPEG is a still-image format and canvas decoding keeps one frame. The detector reads the VP8X animation flag and the ANIM chunks, the plan's first-frame flag is set for every WebP source (yes), and the file row flags the file when the animation check is positive, so nothing is silently discarded.

My WebP had no transparent pixels — why does the row say transparent areas were flattened?

Because the decision is made from the format pair, not by scanning pixels: every WebP → JPEG plan carries the flatten flag, so the composite runs for every file and the note reports the colour used. For a fully opaque image the composite changes nothing — the note is a record of what the pipeline did, not a claim about your pixels.

Why did the JPG come out larger than the WebP?

Because that is what the two byte counts said. The row shows the input and output sizes as true byte counts and a percent change computed from them alone; a larger result is labelled "larger — keep your original". The site publishes no blanket compression percentage, because no percentage is true for every image. As arithmetic on invented byte counts only: 184,320 bytes becoming 236,544 bytes reads "28% larger — keep your original".

Local processing: your images are converted and verified inside your browser and never transmitted — see the methodology page for how to verify that claim yourself.

Convert WebP files to JPG