Notes from the team on craft, formats, and the small decisions behind a good round crop.
The lossless container, what PNG stores
PNG leans on DEFLATE, a lossless algorithm. It writes out each pixel's RGBA values exactly, runs a reversible filter over every scanline first, then squeezes the lot with a zlib-style stream. Lossless here means the values you decompress are byte-for-byte the ones you put in. In the JPG-to-PNG case, the values going in are the pixels the browser hands back after decoding the JPEG, and those already carry every approximation the original JPEG encode introduced. So PNG dutifully records the approximations, not the real scene that was photographed. Measured, a 17 KB JPEG at 1024x768 lands near 105 KB as a PNG, while a 116 KB JPEG at 3840x2160 reaches about 384 KB. The multiples track resolution rather than the JPEG quality setting, which is why they stay roughly steady across content. The container earns its keep by halting decline, not by reversing it.
Why JPEG quality cannot be recovered
JPEG sheds information for good. Its compression runs a cosine transform across 8x8 blocks, rounds the frequency coefficients down to a coarser set, and stores those rounded numbers. That rounding only goes one way, so a coefficient that read 47 before being snapped to 50 can never be nudged back, and the file keeps no memory of the 47. Decoding the JPEG rebuilds pixels from the rounded coefficients, which are guesses at the originals. Wrap those guesses in PNG and you get a flawless copy of a flawed picture. None of this is a shortcoming of PNG or of Araluma, it is just how lossy compression works, with anything dropped at encode time staying dropped. The only route to better JPEG quality is to go back to the uncompressed source or the RAW file.
Measured file size growth
How much a JPG swells on its way to PNG depends on the picture, but the trend is steady. Busy photographs with rich tonal shifts grow the most, because that is the material JPEG compresses superbly while PNG's lossless coder cannot keep pace on such noisy pixels. From this tool's own tests, a 17 KB JPEG photo at 1024x768 becomes a 105 KB PNG, about a sixfold jump, and a 116 KB JPEG photo at 3840x2160 becomes a 384 KB PNG, roughly 3.3 times larger. Flat material such as screenshots and icons suits JPEG poorly to start with and tends to carry more weight there, so its PNG grows less sharply. The lesson is plain, if a smaller output is what you are chasing, turning a JPG into a PNG pushes you the wrong way.
Transparency, the capability versus the content
PNG's 8-bit alpha channel is a feature of the container, letting any pixel carry an opacity from 0 for fully clear to 255 for fully solid. When a JPG is rebuilt as a PNG through the platform image engine, every pixel comes out at 255, fully opaque, because the JPG had no transparency to pass along in the first place. The PNG stands ready to store alpha data, the file simply holds none, since none existed at the source. Putting transparency into the image takes a separate operation, either masking the background by hand in an editor or running an automatic background remover. A remover tuned to spot the subject can deliver a PNG with genuine alpha by setting the background pixels' opacity to zero after the conversion.
EXIF metadata handling
When the file is rebuilt, its EXIF, IPTC, and XMP tags fall away from the PNG on every browser, taking GPS coordinates, the camera body, the shot date, copyright text, and any custom XMP the JPG held along with them. Color profiles diverge a little. Chrome and Safari keep the sRGB tag on what comes out, while Firefox lets it go with everything else. So the PNG is sRGB-safe wherever you open it, though a wide-gamut profile like Display-P3 or Adobe RGB will not last through Firefox. For ordinary web and sharing, dropping the tags is a plus, paring a little weight and stripping location data from your photos. For professional or archival work that must hold its embedded metadata, manage that chain with a purpose-built tool before or after you convert.
Privacy and where the work lands
Where the work lands depends on the count. With a single image, you can check the on-device claim yourself. Open DevTools, move to the Network panel, filter for XHR and Fetch, and run a conversion. No outbound request carrying image data shows up while the encode happens. The JPEG decode and the PNG encode both run on the browser's built-in image engine inside the page tab. With two or more files, 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 lone-file path keeps everything on the device, while a batch trades that for getting many done in one go. When the content is private, converting one at a time leaves nothing to upload.
