JPG to WebP Converter

Guide: Quality parameters and compress-to-target explains what the quality number is to an encoder and how the compress-to-target search uses it. The sections below apply that to this one pair: what the detector sees, what the plan decides, what the encoder is, what re-encoding strips, and how the output is checked. All eight guides are listed at /guides/.

What the detector sees

The first thing this page does with a dropped file is read its leading bytes, not its name. A JPEG begins FF D8 FF. Run on an illustrative head of bytes that starts that way, the site's detector returns JPEG, and that detection — never the extension — is what the rest of the pipeline acts on. The extension is checked afterwards, as a claim to be compared against the bytes. A file named scan.jfif whose bytes start FF D8 FF claims JPEG and is JPEG, so the check reports mismatch: false and nothing needs saying. A file named holiday.png with the same bytes claims PNG but is JPEG: mismatch: true, so the row shows a notice and the file is converted from what it actually is — JPEG — exactly as the methodology page describes.

The reverse case matters on this page in particular. An illustrative file named holiday.jpg whose bytes begin with the PNG signature is detected as PNG while its name claims JPEG (mismatch: true). This lane plans a JPEG-to-WebP conversion and nothing else, so that file is reported as PNG rather than pushed through a plan written for a different source; PNG to WebP is the lane built for it. The detector's full signature list, and the ftyp parsing it uses for HEIC and AVIF, are in How image formats are detected.

What the plan decides for JPEG to WebP

Once the source is known to be JPEG, a pure planning function — the same one every directional converter and both compressors on this site call, with its own tests — returns the decisions the tool will act on. Computed at build time for this pair, with the quality slider at its default, the plan reads:

Two of those values deserve a sentence. The planner decides flattening from the target's capabilities and the source's possibilities together: WebP can hold per-pixel transparency (supportsAlpha: true in the capability table), and JPEG never has any, so the flatten flag is false from both directions. The first-frame caveat is driven by the source container — GIF, WebP and the AVIF image-sequence brand — none of which is JPEG. If you have read a sibling page that warns about either, the absence here is the planner's answer, not an omission.

The output name is derived, not typed. The stem is kept and the extension swapped for the target's canonical one. On illustrative names: IMG_4821.JPG becomes IMG_4821.webp, scan.jfif becomes scan.webp, and a file with no extension at all, receipt, becomes receipt.webp. One case is special: an illustrative JPEG already misnamed banner.webp would get a name identical to its own, so the planner appends a suffix and the download is banner-converted.webp rather than a file that shadows the original.

The quality parameter, and what it is not

WebP is a lossy target in this engine: the capability table marks it lossy: true with a default of 0.85. The planner's own note on that entry is worth repeating: canvas WebP encoding produces lossy WebP, and although the format also has a lossless mode, browsers do not expose it through the canvas encoder. So every position on this page's slider — including the top of its range — produces a lossy file. The slider runs from 5 to 95: the compress-to-target planner's own range, read from that planner at build time (its first probe toward any target is the top, 0.95, and handed an overshoot at an illustrative 0.08 it clamps its next probe to the floor, 0.05, rather than halving below it). The conversion planner accepts both ends: at the floor the plan's quality is 0.05, at the top 0.95. Below its own floor the planner refuses rather than clamping silently — asked for an illustrative 0.04 it answers "Quality must be between 0.05 and 1.", the engine's message rendered at build time. The slider on this page cannot send such a value, so that refusal is the planner's own guard rather than something you will meet while converting. An illustrative slider position of 60 is the engine's 0.6, which the encoder-scale mapping turns back into 60; the default 85 is the plan's 0.85 in the same way.

What the number is not is a prediction. It is a parameter handed to the encoder; it is not a percentage of the original's quality, not a percentage of its bytes, and not a promise about appearance. The tool cannot know, before encoding, how many bytes a given photo will produce at a given setting, and it does not pretend to: it encodes, measures, and shows the real result on the row. This page therefore recommends no setting. If what you actually need is a byte limit — an upload form's "under N KB" — the Image Compressor searches the quality range for you by measurement, and the Quality parameters and compress-to-target guide walks through the planner behind that search attempt by attempt.

The encoder is the browser's own

This lane vendors nothing. The pixels are decoded by the browser via createImageBitmap with imageOrientation: 'from-image', drawn to a canvas, and re-encoded by the browser's WebP encoder. The two self-hosted encoders described on the methodology page — MozJPEG on Compress JPEG, libavif + aom on JPG to AVIF and PNG to AVIF — are not involved here, and no WebAssembly module is fetched when you drop a JPG. Nothing beyond the page's own script is downloaded to do the work. The same fact sets a limit: what the WebP encoder does with a given quality value is the browser's decision, which is one more reason the page reports measured bytes instead of expected ones.

A second lossy generation, as mechanism

A JPEG is already an approximation of the pixels the camera captured. Converting it here decodes that approximation into pixels and hands those pixels to a second lossy encoder, which approximates them again in its own way. What the second encoder receives is the decoded pixels, not the original file, which is the mechanical reason to keep that original. This page does not characterise how visible that second generation is — that depends on the photo, the setting and the viewer, and no sentence written in advance can be true of every file. What can be said mechanically: keep the original JPEG, treat the WebP as a delivery copy, and convert from the best source you have rather than from a copy that has already been through another converter.

What re-encoding strips

Canvas re-encoding carries pixels, not metadata. EXIF — including GPS location, camera model and timestamps — colour-profile tags, and text chunks do not survive the trip from JPEG to WebP. The methodology page presents this as both a feature and a caveat, and it is both here: a converted photo published from this page cannot leak where it was taken, and equally, copyright fields and ICC profiles are gone, so originals should be kept. Orientation is the one thing applied before it is discarded: the decoder honours the EXIF rotation while producing the bitmap, so a phone photo shot sideways comes out upright even though the orientation tag itself is not written into the WebP. What re-encoding does to metadata covers this for every pair on the site.

How the output is verified

A download button on this page means the produced bytes have already been checked twice. First, the output blob's leading bytes are sniffed with the same detector that read the input: a real WebP begins RIFF…WEBP, and if a browser cannot encode WebP and quietly substitutes another format, the detector sees the wrong signature and the row shows an honest error instead of a mislabelled file. Second, the blob is re-decoded and its pixel dimensions compared with the canvas it came from. Only then is the file offered, under the derived name, with its size shown as the output's true byte count.

Where a row shows a percent change, it is computed from the two measured byte counts for that file by a small function whose rounding rules are pinned by tests, and growth is stated as plainly as shrinkage. On invented byte counts, chosen only to show the rules: 1,000,000 bytes to 640,000 reads "36% smaller"; 1,000,000 to 904,000 reads "9.6% smaller" — below the whole-percent boundary one decimal place is kept — while 1,000,000 to 900,000 reads "10% smaller" and 1,000,000 to 899,000 reads "10% smaller", the decimal dropped from the boundary upward; 500,000 to 540,000 reads "8% larger — keep your original"; and 1,000,000 to 999,600, too small to round to a tenth of a percent, reads "less than 0.1% smaller". None of those is a typical result, and none says anything about your photo. The site publishes no blanket compression percentages anywhere, because no percentage is true for every image.

Limits, as the methodology states them

Inputs are limited to 50 megapixels, 100 MB per file, and 40 files or 300 MB per selection; the notice the tool shows for an over-limit file gives the reason as keeping the browser responsive. There is no server to fall back to — the site is static files with no upload endpoint, and its Content-Security-Policy sets connect-src 'self' — so these limits are the tab's limits, stated in advance rather than discovered as a stalled page.

Common misreadings

• "WebP output is always smaller." The tool assumes nothing of the kind. It measures. When the WebP comes out larger, the row says "larger — keep your original" in the same breath.
• "Quality 85 means 85% of the original quality." It is an encoder parameter on a 0–100 scale (the engine's 0.85), not a fraction of anything about your file.
• "95 is lossless." Every position on this page's slider, 5 to 95, produces a lossy file; the engine's capability table records WebP as lossy and notes that the canvas path does not expose the format's lossless mode, so this page never produces it.
• "Renaming .jpg to .webp converts it." It changes a claim, not the bytes. The detector still sees FF D8 FF; dropped here, such a file is converted as the JPEG it is and — for the illustrative banner.webp above — named banner-converted.webp so the result does not overwrite the misnamed original.
• "My EXIF survived because the image is still upright." Uprightness survives because rotation is applied during decoding; the tag that recorded it is stripped with everything else.
• "The missing background-colour control is a bug." The plan's flatten flag is false for this pair: JPEG has no transparency to flatten, and WebP could hold it anyway.
• "The file is uploaded somewhere." The methodology page shows how to watch the Network tab stay empty while you convert, and the connect-src 'self' policy has the browser itself refuse any other origin.

Related tools and guides

The mirror direction is WebP to JPG, where the plan computed for that pair reads needsBackgroundFlatten: true — JPEG cannot hold the transparency a WebP may carry — and animationDropsToFirstFrame: true. PNGs headed this way live at PNG to WebP. For a byte target rather than a quality value, the Image Compressor runs the compress-to-target search. The pipeline itself is documented in The conversion pipeline, and every guide is listed at /guides/.

Frequently asked questions

Local processing: conversion and verification run entirely in your browser — no uploads, ever. Details and DIY verification steps on the methodology page.