JPG to WebP, smaller and sharper. Nothing ever uploads.

Usually, yes. A JPG photo re-encoded as lossy WebP at quality 85 is typically 25–35% smaller with no visible difference, because WebP predicts neighbouring pixels better than JPG does — and this tool shows the before and after size honestly for every file, so you can see the saving instead of taking our word for it. Flat graphics with few colours shrink less, and a lossless WebP can be larger than the JPG for photos, because lossless cannot throw detail away. If a file comes out bigger, the card says so and you can keep the JPG.

Only when the Lossless toggle is on. With it on, the encoder is libwebp's true lossless mode, which stores every pixel exactly — a lossless WebP decodes back to the identical image. But lossless preserves the JPG's existing pixels only: it cannot recover detail the JPG already removed when it was first saved, so a lossless WebP of a JPG is only ever as good as the JPG. With the toggle off (the default), the output is lossy WebP at the quality you pick: quality 85 looks identical to the original for most photos, and quality 100 is visually near-lossless but not pixel-perfect. Keep your JPG as the master copy and use WebP as the published version.

There is no transparency to preserve: JPG has no alpha channel, so every JPG pixel is fully opaque — a JPG photo never has see-through areas. WebP itself does support transparency, but this tool has nothing to carry over from a JPG, so there is no background picker and no transparency preview. If you need a transparent image, start from a PNG and use our PNG to WebP converter instead.

Yes. Phone cameras often store a photo sideways and record the correct rotation in its EXIF orientation tag, which is why some converters return a sideways image. This tool reads the EXIF orientation from the JPG and applies it while decoding, so the WebP is stored upright — and the file card says so when orientation was applied. The EXIF data itself is dropped on re-encode; only the upright pixels survive.

EXIF metadata, including location, camera settings and copyright notes, is dropped on re-encode — which is good for privacy, since a shared JPG can leak where and when it was taken. Orientation is the one exception: it is applied to the pixels so the image stays upright, then discarded. Colour profiles are not carried over either; the output uses the browser's standard colour handling. 16-bit colour does not apply to JPG — JPG is always 8-bit per channel.

JPG is the web's default for photos, but it is a thirty-year-old format: the same photo as WebP is typically 25–35% smaller at quality 85 with no visible difference, and that weight is time your visitor waits — especially on a phone. WebP was built for the web — smaller files, faster loads, better Core Web Vitals and PageSpeed scores — and every modern browser displays it. Keep the JPG as your master copy for editing, and publish the WebP. If the destination does not accept WebP, use our JPG to PNG converter instead.

Usually, yes. Discord, most forums, Slack, WhatsApp and every modern browser display WebP inline, and email clients are catching up — though a few older upload forms and apps still only accept JPG or PNG, so check the destination first. Use the destination presets if the app has an upload size limit: website heroes aim for under 300 KB, blog images under 150 KB, and Discord or forum uploads under 256 KB. The presets aim for the target, they do not guarantee it — the tool reports the size it actually reached.

There is no daily limit and no account. A 25 MB safety cap applies per file and 20 files per batch, because decoding large images in the browser is memory-heavy. Most JPGs saved from a phone or the web are well under 5 MB, far below the cap. Very large images also depend on your device's memory — the encoder runs entirely on your device, so a low-memory phone will struggle with a 50-megapixel JPG where a desktop will not.