Notes from the team on craft, formats, and the small decisions behind a good round crop.
Why a lot of apps still turn WebP away in 2026
WebP has been around for more than a decade, and yet a sizeable share of consumer software still turns it away at upload or display. The reason is rarely capability, since the codec is everywhere. It is inertia and standardisation. Instagram and the broader Meta family fixed on JPEG for upload because it travels best across a worldwide base, and rewriting upload checks demands re-testing on hundreds of device setups. Windows 10's photo viewer needs a separate Store install before WebP works. Enterprise content managers built before 2018 mostly check uploads against a frozen MIME list older than WebP. Print houses, stock libraries, and government portals frequently bake format rules into legal or procurement specs. Every one of these is a genuine wall demanding a compatible format, and JPEG is the key that fits them all.
The transparency snag: why white, and how to swap it
JPEG builds its compression on luma and chroma channels drawn out of the red, green, and blue values, and it leaves no fourth slot where alpha could live. So a JPEG written from a WebP that carries clear pixels must give each of those clear spots a concrete colour. The one that lands by default is white, hex FFFFFF, RGB 255 by 255 by 255, a browser default and not a control this tool puts in front of you. Say your WebP has a clear background and you want a particular colour in the JPG, dark grey behind a logo on a dark page for instance. The move is to open the WebP in any editor that does layers, set a background layer of that colour under the image, flatten the whole thing, and run the flattened file through here. Out comes a JPG wearing your colour right where the transparency had been.
Quality, PSNR, and what hard-to-notice really means
PSNR, the Peak Signal-to-Noise Ratio, is the engineering yardstick for how far a re-encode wanders from its source, read in decibels, where a higher figure means a tighter match. In our end-to-end tests the JPEG writer here logged 43.66 dB PSNR on a 1024 by 768 photo at standard quality. To place that: under about 36 dB the differences turn clearly visible to most people, while 40 dB and above is generally judged perceptually transparent for photographic content. At 43.66 dB the output, for any practical web or print job, is the same image to the eye. Quality is locked in this build, with no slider. Should a chain demand a precise level, a more configurable tool will serve it better.
Weight after conversion: WebP to JPG usually grows
WebP packs photographs tighter than JPEG. Cross back the other way, WebP to JPG, and you move to a looser format, so the output usually ends up heavier than the input. In our runs, a 17 KB WebP photo at 1024 by 768 produced a 15 KB JPEG, a hair smaller in that one case because JPEG happened to suit that image. But on larger shots the swell is steady. A picture arriving as a 32 KB WebP can leave near 50 KB as a JPEG at comparable quality. This is no bug and no sign the tool is stumbling. It is the plain cost of stepping from a tighter format to a looser one, and that growth is simply the toll for getting a file that opens everywhere.
Metadata: EXIF, GPS, and what falls away
WebP files can carry EXIF, GPS location, camera, shutter, aperture, orientation and all. JPEG carries EXIF too. The pipeline here, however, scrubs every trace of metadata from the output. The JPEG that comes back holds nothing but pixels, no EXIF, no IPTC credit fields, no XMP edit log, and no ICC profile under Firefox or WebKit, though Chrome and Edge do keep ICC profiles. This happens at the browser's drawing layer and cannot be switched off. For most publishing it is the welcome outcome, trimming a few kilobytes, removing GPS that could mark where a photo was taken, and stopping camera or editing details from leaking. For archive or legal work where metadata has to live on, reach instead for a dedicated EXIF-preserving editor.
How long a WebP to JPG run takes
Timing it across Chromium, Firefox, and WebKit in our end-to-end work, the JPEG encode on a 1024 by 768 photo measured 16 milliseconds under Chromium, 12 under Firefox, and 17 under WebKit. Grow the photo to 3840 by 2160 and the encode adds roughly 1.5 seconds on Chromium. The span you actually perceive bundles in more than that, the browser pulling the file off disk, the WebP unpack, and the working-surface draw ahead of encoding. Phone shots under 4 megapixels keep the loop beneath a second. Big DSLR photos past 8 megapixels run 2 to 5 seconds in a desktop browser. Mobile devices come in roughly 3 to 5 times slower than desktop on the encode alone, simply mirroring the gulf in mobile CPU power.
