JPG to WebP Converter

Run Lighthouse on any site you built before 2022 and one recommendation shows up like a recurring invoice: serve images in WebP. Mine sat there for a year. The hero photo alone weighed 412 KB, six gallery thumbnails added another 1.8 MB, and every phone visitor paid that toll before a single paragraph of text could paint. Google has pushed WebP in PageSpeed reports for years now, and at some point the hint stops being polite.

The fix is smaller than the warning implies. No build pipeline. No image CDN. No plugin with a settings panel longer than this article. Your JPEGs become WebP files — that's the whole job — and the converter at the top of this page does exactly that. Drop in one file or fifty, set a quality level, watch the size-savings report update as each file finishes, and download the results.

Everything below is the long version. What WebP actually is, what happens inside a JPEG when it re-encodes, how to read the quality slider instead of guessing at it, and the handful of traps that catch people on their first batch. The numbers come from photos I pushed through this exact tool before writing. Your files will differ — but the ratios rhyme.

WebP exists because Google bought a video company. In 2010 it acquired On2 Technologies, the maker of the VP8 video codec, opened the source, and noticed something convenient: a video keyframe is already a complete, self-contained picture. Strip out the inter-frame machinery, keep the intra-frame coding, and you have a modern still-image codec almost for free. WebP shipped that same year. Lossless mode and an alpha channel arrived in 2011, and animation support landed in 2013.

That lineage pays off in ways JPEG never could. One format, four tricks:

• Lossy photos — the VP8 keyframe path, typically 25–34% smaller than JPEG at matched perceptual quality, according to Google's published SSIM study
• Lossless mode — VP8L, a completely separate compressor that beats PNG by roughly 26% on typical material
• An alpha channel — soft-edged transparency, stored lossy or lossless, which JPEG simply cannot represent
• Animation — a container feature, so looping clips ride the same efficient coding that stills do

So why does the JPEG in your downloads folder still exist? Inertia, mostly. WordPress converts uploads automatically now, and most commercial CDNs follow suit, but hand-built sites, older CMS installs, client email attachments, and stock libraries keep minting fresh JPEGs every single day. The last mile of the WebP transition is manual, and it runs through a page like this one.

1. 1

   Load the JPEGs

   Drag files onto the drop zone or click through the picker. Whole folders work; the queue lists every file with its current size so you can see the starting point.

2. 2

   Pick a quality level

   Start at 80 for photos and 90 for screenshots or anything with fine text. The slider runs 0–100 and maps straight onto the codec's quantizer.

3. 3

   Read the savings report

   As each file encodes, the tool shows before-and-after sizes plus the percentage saved. Everything updates live, so you can nudge quality down until the number you need appears.

4. 4

   Inspect at full zoom

   Open the preview at 100% and check the places where compression damage shows first: sharp text edges, rooflines, hair against bright sky. If those survive, the rest of the image is fine.

5. 5

   Adjust and re-run

   Nothing is locked in. Change the quality setting and the queue re-encodes; only the files you've already eyeballed need a second look.

6. 6

   Download

   Grab files individually or take the whole batch at once. Output names keep the original filename stem with a .webp extension.

JPEG, at its heart, is a 1992 procedure. Slice the image into 8×8 blocks, run a discrete cosine transform on each, divide the coefficients by a quantization table, and Huffman-code whatever survives. No block ever talks to its neighbors. Every block is described from scratch, even when the block next door is the same flat shade of sky.

VP8's keyframe coding — which is what lossy WebP uses — thinks in relationships. The image becomes 16×16 macroblocks, each split into 4×4 sub-blocks. Before any pixel is transformed, every sub-block is predicted from the reconstructed edges above and to its left: vertical continuation, horizontal continuation, one of eight diagonal modes, or a flat average fill. Only the prediction error — the residual — gets transformed and quantized. A wall that matches its own prediction costs almost nothing to describe.

Three further refinements stack on top of that:

• A second-order Hadamard transform across the sixteen luma DC terms, squeezing redundancy out of neighboring sub-blocks before entropy coding even begins
• A boolean range coder — arithmetic coding, effectively — that packs symbols into fewer bits than JPEG's Huffman tables manage
• A deblocking loop filter that smooths the 4×4 grid seams after reconstruction, which is why low-quality WebP goes soft instead of going blocky

The wrapper is older technology wearing a modern label: a RIFF container with a WEBP tag, a VP8 chunk holding the frame, and optional ALPH, ICCP, and EXIF chunks when those features are present. The dimension ceiling sits at 16,383 pixels per side, which your camera will never approach — your 40,000-pixel-wide museum panorama might.

Color gets its own economy. Both JPEG and WebP typically store chroma at half resolution in each direction — 4:2:0 subsampling — because your eyes resolve fine detail in brightness far better than in hue. That's invisible on skin and sky. It's occasionally visible on hard color boundaries: a red logo on white can show faint dark fringes at the character edges, because the color channel simply doesn't have enough samples to draw a crisp line. The fix is quality 90 or above, where libwebp keeps chroma at full resolution, or lossless mode for anything typographic.

Here is a single photograph pushed through the tool — 2,400×1,600 pixels, exported from Lightroom at JPEG q85, 512 KB on disk:

Two caveats before you screenshot that table as a promise. First, JPEG and WebP quality numbers live on different scales — WebP q75 sits visually near JPEG q85, which is why the savings column reads generous. When researchers match perceptual quality properly, using SSIM rather than eyeballs, Google's published advantage is 25–34%. Second, subject matter moves the numbers: skies and out-of-focus backgrounds compress beautifully, while a hayfield at golden hour fights you on every setting. The table is a map, not the territory. The live preview is the territory.

Multiply across a page. Six images like this on a homepage drop from 3.1 MB to 1.7 MB at q80. On a throttled 4G connection — call it 1.6 Mbps effective — that hands roughly seven seconds back to the visitor before first paint finishes. On fiber, nobody notices. Your mobile audience is not on fiber.

A more honest test is a batch, because averages hide file-level drama. Thirty-six product photos, all 2,400×1,600, exported identically at q85: 14.2 MB of JPEG going in. The tool returned 8.9 MB of WebP at q80 — a 37% cut — with per-file savings ranging from 31% (a wooden background full of grain) to 42% (a product floating on seamless white).

The hero shot went from 912 KB to 548 KB. It was also the Largest Contentful Paint element, which made that single file the difference between a red LCP score and a green one on mobile. Nothing else on the page changed. One conversion, one metric, one color on a report.

Batch behavior has a practical ceiling: memory. Each 2,400×1,600 image occupies about 15 MB of RAM while decoded, so a 200-file queue means 3 GB of pixels living at once. Modern laptops manage that. Older phones do not. Work in groups of fifty or so if the tab starts to feel heavy.

After a few thousand conversions you start predicting file sizes before the encoder finishes. Out-of-focus backgrounds, overcast skies, studio backdrops, and skin shot with soft light all collapse beautifully — prediction and transform coding love smooth gradients. Those are the images where 50% savings arrive without any visible cost.

The stubborn material is just as predictable. Foliage and foliage-adjacent texture — grass, hay, ferns, confetti — is high-frequency detail in random arrangement, which is the exact thing quantization discards first. Fine woven fabric, dense brickwork, and hair backlit against a bright window join the same club. You'll see savings of 20–30% instead of 45% there, and pushing the slider harder starts to smear the texture into an oil-painting look. Accept the smaller win on those files; the encoder is being honest with you.

Screenshots and UI captures sit in a third category. Flat fills, few colors, crisp text edges — that's territory where WebP's lossless mode or a high lossy quality both work, and where JPEG's 8×8 grid does visible damage around every glyph. If you're converting documentation screenshots rather than photographs, q90 is the floor, and it will still undercut the original JPEG by a comfortable margin.

• Progressive JPEG can feel faster. A progressive JPEG paints coarse-to-fine as bytes arrive; WebP decodes in a single pass. On a genuinely slow connection, the JPEG can appear to load sooner even while weighing more. For the smallest perceived load times, this is the one corner where JPEG keeps the crown.
• CMYK JPEGs misbehave. Files exported from Adobe apps in CMYK or YCCK occasionally decode with shifted or inverted color in browsers. If your output colors look wrong, re-export the source in sRGB and convert again.
• EXIF orientation is applied, then erased. Modern browsers rotate pixels to the intended orientation before the canvas ever sees them, so your output stands upright — but the orientation flag itself doesn't survive re-encoding. GPS and camera metadata don't either. Keep your originals if an archive needs them.
• Animation doesn't apply on this path. JPEG sources are single frames, so the output is always still. Going the other direction is different: if your WebP is animated, the reverse tool hands you frame one, a trade the WebP to JPG Converter page covers in detail.
• 16,383 pixels per side is the hard ceiling. The practical limit is your device's memory, and it usually arrives first.

Performance engineers, obviously — people paid to move Core Web Vitals from amber to green. But the heaviest users of JPG-to-WebP tools are the ones you'd expect less.

• Marketplace sellers, whose shop banners and gallery images compete with a 4 Mbps mobile reality — every platform that accepts WebP rewards the smaller upload
• Photographers delivering web galleries, where clients get faster pages and the photographer ships the same portfolio twice
• Bloggers on static sites with no image pipeline in the build, who convert by hand thirty seconds a month
• Students and job-seekers on free hosting with bandwidth caps, for whom 2 MB of JPEG is a genuine crisis
• Designers handing off assets — the developer asked for WebP, the design tool exports JPEG, and this page is the bridge between the two

The common thread is control of the delivery format. If you decide which bytes leave your server, you should decide WebP for photographic content. If a platform or a client decides for you, bookmark this page for the day they change their mind — platforms have been quietly accepting WebP for years, and almost none of them announced it.

It's the obvious counter-argument, so let's take it seriously. Re-compress a 512 KB JPEG at JPEG quality 60 and you land near 190 KB — roughly the size of a q70 WebP from the same source. Open both at 100% zoom. The JPEG shows ringing around every hard edge and 8×8 stair-stepping in smooth gradients. The WebP shows a slight overall softness. Same bytes, different damage, and the softness is the one human vision forgives.

The reason is structural. JPEG spends its bits re-describing flat areas block by block. VP8 spends nearly zero bits there and banks them for edges. At equal file size, the smarter allocator wins, and no amount of JPEG slider fiddling changes the allocation strategy. When a form portal or a print kiosk demands JPEG specifically, compress it as far as you must. When you control the delivery format, WebP is the better instrument for photographic content.

The same 512 KB test photo, encoded three ways on the same machine:

AVIF wins the size contest with room to spare. It's built on AV1, a codec a full generation newer than VP8, with native 10-bit color that keeps gradients from banding. The cost is CPU: one encode took roughly nine times longer than WebP on this machine, which matters at batch scale and matters enormously if you re-encode on every upload. For a single hero image, take the AVIF. For a whole site, WebP remains the sane default, with AVIF layered on through a picture element for the files that earn it. The AVIF Converter handles that side of the street.

The point of all this is delivery, so here is the markup that puts the converted files to work. One picture element, one WebP source, one JPEG fallback for whatever device in your audience still can't read the format:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Coastal trail at sunset" width="2400" height="1600">
</picture>

The browser picks the first source it understands and ignores the rest, so modern visitors get the small file and the last iPhone 6 holdout still gets an image. Keep the width and height attributes on the img so layout doesn't shift while it loads. If you later add an AVIF source above the WebP one, the same pattern extends without changes — smallest format first, JPEG last, and every visitor lands somewhere sensible.

The tool decodes and re-encodes inside the browser's canvas — the same image machinery any page uses to draw a thumbnail. No pixel crosses the network. You can verify the claim yourself: open your browser's network panel, load this page, convert a folder of photos, and watch the request list stay empty. Or load the page, switch on airplane mode, and keep working. Both tests pass because the entire pipeline is JavaScript running on your machine.

That also settles the batch-limit question before it's asked. There is no server quota, no daily allowance, no per-file fee — there's no server involvement to meter in the first place. The ceiling is your RAM, and the queue tells you when it's being ambitious rather than failing silently at file 140.

There's a speed argument hiding in the privacy one. An upload-based converter pays a round trip per file — your photo travels up, waits in a queue, gets processed on someone else's schedule, and travels back. A local encode starts the instant you drop the file and runs as fast as your machine's cores allow. On a typical connection, converting 36 photos locally finishes before a single upload-based competitor has finished its third file. Privacy and speed are the same design decision here.

Format conversion is usually the first move in a small chain. The gallery that just became WebP often needs a hard size cap for an upload form, or the reverse conversion when a client's older software draws a blank at the .webp extension. These neighbors cover the rest of the chain, all in the same browser-only style:

• PNG to WebP Converter — the same conversion with an alpha channel to protect, plus a true lossless mode
• Image Compressor — when a portal enforces a KB cap and you need to hit a number, not a format
• WebP to JPG Converter — the return ticket, for software and services that still reject WebP