Notes from the team on craft, formats, and the small decisions behind a good round crop.
Why photographic PNGs are so large
PNG promises to record every pixel without losing any, and that promise is expensive on a photo. With millions of gently shifting tones there is almost nothing for the compressor to predict or collapse, so the file balloons. A run-of-the-mill 1600x1200 photo can sit at 3 to 5 MB as a PNG, yet the very same image as a JPEG at quality 85 fits in 200 to 400 KB. The difference comes down to the cosine transform JPEG leans on, which carves the image into 8x8 blocks, sheds the high-frequency detail the eye barely registers, and packs what is left tightly. Continuous-tone material, which is to say nearly all photography, shrinks dramatically. PNG's perfect fidelity earns its keep on flat graphics and works in progress, but it is simply the wrong wrapper for a photo you mean to share.
Transparency and the alpha channel
An 8-bit alpha channel lets a PNG record any level of opacity per pixel, from fully clear to fully solid. JPG offers no such field, so transparency has nowhere to live. When the image engine rebuilds a PNG as JPEG, it first lays the picture over a chosen backdrop, and that backdrop defaults to white, which is exactly why clear regions read as white afterward. The takeaway is blunt, a transparent JPG cannot exist, because the format has no concept of it. When the cut-out has to survive, WebP or the untouched PNG are your only routes. Araluma settles on white as the fill because it blends into the documents, slides, and storefront listings where these JPGs most often end up.
Measured encode performance
All of these come off Chrome 148 on a Linux desktop, leaning on the browser's own JPEG encode. At 0.12 MP, a 400x300 thumbnail wraps in about 10 to 15 ms. Bump to 0.78 MP, a 1024x768 frame, and it sits near 13 to 20 ms. An 8 MP shot at 3840x2160 needs roughly 1.4 seconds, and even a 48 MP monster at 8000x6000 only asks for around 1.5 seconds. Writing a JPG this way handily outpaces writing a PNG of the same picture, and it utterly outruns AVIF, which has to load a separate module and can grind for 25 seconds on that 48 MP image even on a desktop. Taken together, this is among the quickest routes anywhere in the convert family, and it costs nothing extra to fetch, since the JPEG writer already lives in every browser.
EXIF and metadata handling
Rebuilding the image clears its EXIF, IPTC, and XMP tags from the resulting JPG on every browser, which sweeps out GPS coordinates, the camera body, the capture timestamp, copyright text, and any custom fields the PNG was carrying. ICC color profiles take a separate route, where Chrome and Safari keep the sRGB profile on the output while Firefox strips it with everything else. So the JPG is sRGB-safe everywhere, but a wide-gamut tag such as Display-P3 or Adobe RGB will not make it through Firefox. If your pipeline depends on holding all that metadata, manage it with a purpose-built tool afterward. For everyday web and sharing, losing the tags is welcome, trimming a little weight and pulling location data out of your photos.
When JPG artifacts are visible
JPEG reasons in 8x8 blocks. Drop a hard jump between two very different colors inside one block and JPEG compression can only sketch it with a handful of frequency terms, leaving ringing, a faint halo of lighter or darker pixels hugging the edge. Photographs hide this well, since their edges are never razor-clean and the surrounding micro-variation masks the approximation. But screenshots, logos, boxes with crisp borders, lettering, or neighboring slabs of flat color expose it at any quality, because that is precisely the signal the math struggles with. The rule writes itself, keep screenshots, logos, and text-heavy art out of JPG. Leave them in PNG, or move to WebP for a lean file that sidesteps the ringing altogether.
Privacy and where the work lands
Where the work lands depends on the count. With a single image, nothing leaves the browser, and you can check it live in seconds. Open Chrome DevTools, switch to the Network panel, filter for XHR and Fetch, and convert a file. Nothing appears while the encode runs. With two or more, Araluma sends them to our server, which converts them, bundles the result, and returns a download link. That link and the converted files are cleared in about 2 hours. The single-image path keeps everything on the device, off the network, while a batch trades that for getting many files done in one go. For a screenshot of something private or a photo stamped with your location, converting one at a time keeps it on your machine, a genuine difference, not a slogan.
