How we test

In the 2026-10-11 batch benchmark, elapsed time started when files were handed to the page and ended at the last completed image or the finished ZIP. Status was polled about once a minute, so the recorded time has about a minute of precision. Other runs timed individual stages or divided successful outputs by processing time, excluding checks and saving. Each guide states which interval its numbers cover.

That benchmark sampled memory every 2 seconds, summing working set and private bytes across the benchmark browser's processes and reporting their peaks separately. These totals include more than JavaScript memory. A GPU-process investigation instead followed individual processes; its growth per photo was calculated from the first and maximum samples.

We record output byte counts and check saved files. Checks differ by run: the 2026-10-11 Chrome ZIP had its entry count checked and 6 sampled outputs decoded. The earlier Firefox Converter ZIP received a full archive integrity test, input-name and CRC checks, and 40 sampled decodes with dimension checks. An entry-count check alone does not prove that every output decodes.

The desktop records include other work running on the machine. The benchmark logged CPU load, free memory and heavy processes before runs. The night-run report also records shared-machine load. An automated Firefox build is identified separately from stock Firefox: its download instrumentation can hold data and change the memory reading.

Phone results come from the recorded native-picker and remote-debugging checks. They do not establish that the full desktop corpus finishes on a phone, or that every Android browser can decode HEIC.

The large batch contains 10,000 files: 8,500 JPG, 1,000 PNG and 500 HEIC, about 33.3 GB of logical file data. It repeats 83 distinct generated images under different names, with hard links used to build the set. Repeated images and the operating system's file cache can help reads; this is a pipeline stress test, not 10,000 independent photographs.

Single-file probes use different inputs. The 108 MP JPEG is 12000 × 9000 pixels and 18,888,121 bytes; its desktop stage probe ran three fresh-page conversions per browser. A later large JPEG has 199,756,800 pixels. Animation and container checks use small samples with known frame counts and HEIC files that distinguish a primary still from a timed sequence.

The 2026-10-11 comparison used the same batch and job: WebP at quality 80%, no resizing, and each tool's fastest reasonable setting. FluffyBench used Image Space Saver with Fast and Download as ZIP enabled. Runs still going at five times FluffyBench's elapsed time were stopped and recorded as exceeding that cutoff.

A tool that could not be tested was recorded as not compared. Free-plan limits were read on the test day. Where the automated file hand-off broke a site, a normal-upload control was used to distinguish a test-driver problem from the tool's behavior. These conditions belong with the result; they do not support an unqualified ranking.

The run records identify the tested code revision. The 2026-10-09 night run used an instrumented build; the 2026-10-11 benchmark used the stable preview build. Instrumented stage timings and ordinary end-to-end timings answer different questions, so we keep their methods separate.

When code behind a figure changes, that figure needs a new measurement before it describes the changed release. A dated historical result remains a result for its recorded setup. Missing runs, unknown versions and narrower output checks stay explicit in the guide.

For the batch results and their archive checks, read Converting 10,000 photos in a browser. The large-image guide separates stage timings from the phone download reproduction.