What Happens When You Convert a 48.8-Megapixel HEIC in Your Browser?

The test image

Our test file, IMG_1089.HEIC, was a high-resolution iPhone-style photograph measuring 8064 × 6048 pixels.

The compressed file is small. The image isn't.

HEIC compression means the original file can remain extremely small compared with the amount of information represented by its pixels. Once decoded into RGBA, every pixel requires four bytes.

48,771,072 pixels × 4 bytes
= 195,084,288 bytes
≈ 186.05 MB

This is the raw RGBA buffer, not total browser memory usage. A real browser process can require additional memory for the WebAssembly heap, decoder, canvas, intermediate buffers and other allocations.

Decoding took about two seconds

We ran the pixel-decode operation ten times to measure repeatability. The results were remarkably close together on the test system.

Encoding to JPEG was cheap by comparison

JPEG at quality 92 took 818.5 ms to encode. Combined with the measured pixel decode, the approximate end-to-end pipeline was 2.91 seconds.

WebP was the surprise

WebP produced the smallest output of the three formats, but the browser spent dramatically longer encoding it. Including HEIC decoding, the full pipeline was approximately 13.84 seconds.

PNG was fast to encode, but huge

PNG encoded substantially faster than WebP but produced a file more than ten times larger than the original HEIC. That is not really a failure of PNG: lossless PNG is simply a poor fit when the objective is compact photographic storage.

The full comparison

Output size tells a different story

Raw benchmark data

What the benchmark actually tells us

Methodology

The benchmark used a real 48.77-megapixel HEIC image. The image was decoded inside the browser using a WebAssembly HEIC decoder. The resulting pixels were placed into an RGBA ImageData buffer and then encoded through the browser's canvas encoding pipeline.

JPEG and WebP were encoded at quality 92. PNG used the browser's lossless encoding path. Decode timing was measured separately from output encoding so that the cost of the input format could be distinguished from the cost of the output format.

The figures represent this specific browser, machine, image and implementation. They should not be interpreted as universal performance figures for every browser or HEIC decoder.

Caveats and limitations

This is one benchmark, not a universal ranking of image formats. Results can change significantly with CPU architecture, browser version, operating system, WebAssembly implementation, image dimensions, image content, encoder settings and memory availability.

The most useful next experiment would test multiple images at 12 MP, 24 MP, 48 MP and 50+ MP. That would let us investigate whether decode time scales roughly linearly with pixel count and whether browser memory pressure becomes a significant factor at higher resolutions.

Conclusion

A 6.81 MB HEIC file can conceal nearly 186 MB of raw pixel data. In this test, decoding the image took approximately 2.09 seconds before output encoding even began.

JPEG added less than a second and produced an 11.24 MB file. PNG took about 1.40 seconds to encode but produced a 71.93 MB output. WebP was the outlier: its 9.74 MB output was the smallest, but encoding required 11.75 seconds.

The important lesson is that input file size is not the same thing as processing cost. A few megabytes on disk can represent tens or hundreds of megabytes of raw image data once decoded.

HEIC conversion tools

If you arrived here looking for the practical side rather than the benchmark, these are the main FileTools HEIC conversion routes:

Frequently asked questions