The short answer: when you convert to a lossless format in the browser, the pixels usually come through exactly. 92 of our 207 measured outputs were bit-for-bit identical to the source, and every remaining lossless result had a specific cause: a colour profile, a different HEIC decoder, SVG rendering or a PSD's built-in preview. Uncompressed formats cost a lot of space: BMP and PPM came out 1.8× the size of PNG on our photo, TGA and TIFF 2.4×, PSD 3.0×. JPG, BMP and PPM flattened transparency onto white every time, and camera metadata (EXIF) was removed from every one of the 41 outputs whose source had it.
The tests also found four bugs in our own converters, which we fixed in October 2026 before taking the measurements below. They're described further down, because each one is a trap you can hit in other tools too.
What we converted
We used two test files, each saved in all 13 formats our converters read: AVIF, BMP, GIF, HEIC, ICO, JPG, PNG, PPM, PSD, SVG, TGA, TIFF and WebP. The photo is an iPhone 14 Pro Max shot scaled to 1600 × 1200 with its EXIF kept; the PNG and ICO versions carry a Display P3 colour profile. The graphic is an 800 × 600 image with a transparent background, gradients, a soft shadow and text. The ICO versions are 256 × 192, the largest an icon allows at that shape, and the SVG exists only for the graphic. Each source went to each of the nine output formats we offer (AVIF, BMP, JPG, PNG, PPM, PSD, TGA, TIFF, WebP), which gives 108 conversion pairs and 207 measured files.
Lossless targets: exact, but large
PNG, BMP, PPM, TGA, TIFF and PSD all store pixels without loss, so in theory any of them should reproduce the source exactly. In our run, 92 of the 138 lossless results did. The table shows what the same photo and graphic cost in each format when converted from an uncompressed source (BMP for the photo, TGA for the graphic), so the starting pixels are the same in every row.
| Output | Photo (1600 × 1200) | vs PNG | Graphic (800 × 600) | vs PNG | Keeps transparency |
|---|---|---|---|---|---|
| PNG | 3,221,389 bytes | 1.00× | 341,998 bytes | 1.00× | Yes |
| BMP (24-bit) | 5,760,054 bytes | 1.79× | 1,440,054 bytes | 4.21× | No, white |
| PPM (P6) | 5,760,017 bytes | 1.79× | 1,440,015 bytes | 4.21× | No, white |
| TGA (32-bit) | 7,680,018 bytes | 2.38× | 1,920,018 bytes | 5.61× | Yes |
| TIFF (uncompressed RGBA) | 7,681,000 bytes | 2.38× | 1,921,000 bytes | 5.62× | Yes |
| PSD (layer + composite) | 9,618,224 bytes | 2.99× | 1,266,656 bytes | 3.70× | Yes |
The arithmetic explains most of it. 1600 × 1200 is 1,920,000 pixels. BMP and PPM store 3 bytes per pixel (5,760,000 bytes plus a small header), and TGA and TIFF store 4 bytes per pixel (7,680,000 plus header), because our TIFF and TGA writers always include an alpha channel. PNG compresses, so it lands well under any of them, and the gap is widest on the graphic, whose flat areas and transparent background compress very well. PSD stores the image twice, once as a layer and once as a flattened composite, so it's the largest on the photo, though on the graphic it came out smaller than TGA or TIFF.
If you need a lossless file and the receiving software accepts PNG, PNG is the one to pick. Use TIFF, BMP, TGA or PPM only when a specific program, printer or pipeline asks for it.
Why 46 lossless results weren't bit-exact
- Colour profile (PNG and ICO photo, 11 results). The browser converts an image with a Display P3 profile to sRGB when it draws it, and the output has no profile. Measured against the file's raw values that is 33.6 dB PSNR, but SSIM 0.9995: the colours are the same colours expressed in a different colour space, not damage.
- HEIC (12 results). Our outputs were within 3 levels (out of 255) on the photo and 4 on the graphic of our reference decoding (64.2 dB and 64.7 dB). Two HEIC decoders rarely agree to the last bit.
- AVIF and WebP graphic (12 results). Off by at most 1 level (59.6 dB and 58.5 dB). The opaque photo in the same formats converted exactly, so this is rounding in the transparent graphic, not visible change.
- SVG (6 results). Within 14 levels of our reference render (62.1 dB). Two renderers anti-alias edges a little differently.
- PSD graphic (5 results). 29.3 dB against the layer. More on this below.
Lossy targets: JPG, WebP and AVIF
At the converters' default quality of 85%, all three lossy formats cut the photo to under a tenth of the PNG's size. The table uses the same uncompressed sources as above.
| Output | Photo size | Photo SSIM | Graphic size | Graphic SSIM | Time (photo) |
|---|---|---|---|---|---|
| JPG | 295,873 bytes | 0.9798 | 31,738 bytes (no transparency) | 0.9946 | 0.9 s |
| WebP | 225,300 bytes | 0.9772 | 41,474 bytes | 0.9977 | 1.4 s |
| AVIF | 302,821 bytes | 0.9903 | 33,187 bytes | 0.9980 | 7.4 s |
Across the nine photo sources without a colour profile, the spread was narrow: JPG 286,517–305,486 bytes at SSIM 0.9738–0.9838, WebP 221,672–244,690 bytes at 0.9741–0.9810, AVIF 291,709–361,848 bytes at 0.9902–0.9938. So at the same quality setting, WebP gave the smallest photo, and AVIF a file about the size of the JPG but with clearly higher fidelity. The quality slider doesn't mean the same thing in each encoder, so if you want AVIF to be smaller rather than better, lower its quality.
For the graphic, the deciding factor is transparency, not size. JPG has none and flattens the background onto white. WebP and AVIF kept the alpha channel in every test and still came out at roughly a tenth of the PNG (12% and 10%).
AVIF is slow to encode in Chrome and Firefox because it runs in WebAssembly on your device (see the third bug below). In our run, AVIF output took 6.8–13.5 seconds for the 1600 × 1200 photo and 2.1–4.2 seconds for the 800 × 600 graphic, against roughly 1 second for JPG from most sources. For a batch, WebP is the faster option; for the best quality per byte, AVIF is worth the wait.
Where transparency was lost
84 of our results started from a file with transparency. The 30 that lost it are exactly the conversions to JPG, BMP and PPM, which have no alpha channel; Pixohub flattens those onto white. All six formats that can store alpha (PNG, WebP, AVIF, TIFF, TGA, PSD) kept it from every source, including HEIC and ICO, which needed two of the fixes below. If you need a transparent background, check the output format before anything else.
EXIF was removed every time
41 results came from a source with camera metadata (the HEIC, JPG, PNG, TIFF and WebP photos). None of the outputs kept it: the conversion redraws the pixels on a canvas, and the canvas has no metadata. Orientation is applied to the pixels first, so photos stay upright. This removes GPS location and camera details too, which is usually what you want before sharing; if you need the metadata, keep the original. To check a file, use the EXIF viewer.
The bugs our tests found, and what we changed
Running every pair against a measured reference showed problems that a quick visual check missed. All four were fixed in October 2026, and the numbers above come from the fixed version.
- HEIC colours and transparency. Our previous decoder, heic2any 0.0.4, shifted colours: compared with Apple's own decoder (macOS
sips) the result scored about 27 dB PSNR. It also dropped transparency. We replaced it with heic-to, which bundles a current libheif. It matches Apple's decoder to about 48 dB on the photo and keeps alpha. One limit remains: heic-to doesn't apply the HEIC's colour profile, so the values pass through unchanged, and a Display P3 HEIC looks slightly less saturated when shown as sRGB. Try it on HEIC to JPG or HEIC to PNG. - ICO icons showing up empty in Chrome. An ICO file can hold PNG images. When that PNG has no alpha channel, Chromium renders the icon as fully transparent; Firefox and WebKit render it correctly. Pixohub now finds the largest PNG entry in the ICO and decodes it as a normal PNG, which works in every browser. See ICO to PNG.
- AVIF and WebP output that was really PNG. Chrome and Firefox can't encode AVIF through the canvas, and Safari can't encode WebP. Instead of failing, their canvas silently returns a PNG. Pixohub now checks what it got back and, if it isn't the requested type, encodes with bundled libavif or libwebp compiled to WebAssembly (the encoders from Squoosh's @jsquash packages). This is why AVIF takes several seconds in Chrome.
- PPM files refused in Chrome. Our upload's file type check turned .ppm files away in Chrome, so PPM conversions couldn't start. PPM files are now accepted, and the PPM decoder reads both binary (P6) and text (P3) files.
A caveat for PSD files
A PSD contains a flattened composite image alongside its layers, and Pixohub reads the composite. For our transparent test PSD, written by macOS sips, the composite's soft edges differ from its layer, which is why the PSD graphic results score 29.3 dB against the layer (SSIM 0.9915). The opaque photo PSD converted exactly. If a converted PSD looks different from what you see in your editor, the composite is the likely cause. A PSD saved from Photoshop with Maximize Compatibility turned off may have no usable composite at all, so turn that option on before saving.
What to take from this
- Need an exact copy? Convert to PNG. It was lossless wherever the source allowed, the other lossless formats were 1.8–3.0× its size on the photo, and it keeps transparency.
- Need a small file? WebP gave the smallest photo at default settings; AVIF gave the highest SSIM at a JPG-like size but takes several seconds to encode in Chrome and Firefox.
- Need transparency? Avoid JPG, BMP and PPM; they turn the background white.
- Need the camera metadata? Keep the original; converted files have none.
- Converting from a wide-gamut source (Display P3 PNG, iPhone HEIC)? Expect small colour differences, because the output is in sRGB without a profile.
- Many files at once? Bulk format convert uses the same encoders.
How we tested
On 24 October 2026 we drove each of Pixohub's 108 conversion pages (for example /png-to-webp) in Chromium via Playwright 1.64.1 on an Apple M2 Mac. A script uploaded the test file, waited for the result and saved exactly what the download button returns, with default settings (85% quality for JPG, WebP and AVIF). The test files are described in our editorial policy; the method is in how we test the tools.
We decoded each source and output with Pillow (pillow-heif for HEIC; for SVG the reference is its 800 × 600 render, and for PSD the layer image), composited both onto white, and compared them at full resolution. Identical means every RGB value matched. PSNR is on the RGB values; SSIM is on luminance. We also recorded file size in bytes, whether the output has transparency and camera EXIF, and the time from choosing the file to the download being ready. The HEIC comparisons with Apple's decoder used macOS sips output as the reference.
Limits: this is one photo and one graphic, so sizes on your own images will differ, though the ratios between uncompressed formats are fixed by the arithmetic. Times are from one machine and one browser; Safari uses its own AVIF encoder and our WebP fallback, so its times differ. Comparing against a white background hides differences in fully transparent pixels. GIF sources are 256-colour, which is why the GIF photo results start from a different image than the others.