Why can converting a very large image take so long in a browser?

A photo can be small enough to download quickly and still give your browser a lot of work. It expands into millions of pixels—and saving those pixels in a new format can take most of the time.

FluffyBench · 7 min read · Measured October 8, 2026 with FluffyBench's WebP converter

Why can a small image file need so much memory?

A JPEG is like a packed suitcase: it takes less room closed than it does with everything spread out. To show or change your photo, the browser unpacks it into a grid of colored pixels. Width times height tells you how many positions that grid has.

Our photo occupied about 19 MB on disk and expanded into 108 million pixel positions. One four-byte-per-pixel grid for that photo is a calculated 432 MB.

A JPEG of about 19 MB expands into 108 million pixels, about 432 MB for one calculated grid. — The grid estimate describes one unpacked picture; the browser also needs memory for other work. Measurement method and sources

So a quick download doesn't mean a quick conversion. The browser still has to work through the unpacked picture, and then write a new file.

Why can saving a converted photo take longer than opening it?

Opening a JPEG unpacks its pixels; converting it also draws those pixels on a canvas, the browser's drawing surface, and encodes them into a new file.

Decode opens the picture, Draw prepares it, and Encode writes the chosen format.

In FluffyBench's WebP converter, encoding accounted for most of the wait: about 29–36 seconds. These results come from one photo on our desktop.

Chrome: conversion stages

Decode: 0.49 s
Draw: 0.06 s
WebP encode: 36.01 s

Firefox: conversion stages

Decode: 0.80 s
Draw: 0.18 s
WebP encode: 28.62 s

Total elapsed time to Done

Chrome: 38.05 s
Firefox: 29.85 s

Total elapsed time is separate from the three stages and includes other work between them.

That's why seeing the photo appear isn't the end of the job. A preview can be ready while the browser still has the new file to write.

Can megapixels predict conversion time?

A megapixel is a million pixels, so it tells you the amount of picture, not a finish time. We compared centered 24 MP and 48 MP crops from the same photo.

An outline of the 108 MP full frame contains centered 48 MP and 24 MP crop boundaries, drawn from their recorded dimensions. — Both crops remove the edges of the original photograph; resizing would keep the whole frame.

The larger crop had about twice the pixels and took more than 6 times as long to encode in both browsers. Pixel count isn't a stopwatch.

Chrome

Scale from zero to: 10.88 s

24 MP centered crop: 1.67 s
48 MP centered crop: 10.88 s

Firefox

Scale from zero to: 10.88 s

24 MP centered crop: 1.57 s
48 MP centered crop: 10.54 s

The two crops used the same WebP quality setting; bars show encoding time.

Can changing the output format shorten the wait?

Yes: on the same full photo, JPEG at quality 92 encoded in under a second, while both WebP settings took tens of seconds. These separate browser API comparisons show how much the chosen format can matter for this picture.

Chrome

Scale from zero to: 29.47 s

WebP at quality 92: 29.47 s
WebP at quality 80: 24.72 s
JPEG at quality 92: 0.66 s

Firefox

Scale from zero to: 29.47 s

WebP at quality 92: 28.42 s
WebP at quality 80: 24.59 s
JPEG at quality 92: 0.53 s

Encoding time alone, with a common scale across browsers; these results don't rank appearance.

A faster file still needs to suit its destination. Quality numbers also aren't a common measure across formats: JPG 92 and WebP 92 don't promise the same look. For help choosing a quality setting, see what re-saving does to an image.

Doing it in FluffyBench: resize as much as you need

FluffyBench's Image Space Saver can make a smaller whole-frame copy, leaving fewer pixels to draw and encode. If you need all the detail, it can keep the original dimensions. Resize, compress or convert? explains which change fits your job.

Start with one of the photos you plan to use. This walkthrough chooses JPG and smaller dimensions; use the bounds your destination asks for.

Step 1. Choose one photo to try before adding a batch.
1. Choose images opens your file picker.
Step 2. Open Settings to choose the output.
1. Settings opens the image controls.
Step 3. Choose Profile → Custom to reveal the format choice.
1. Custom lets you choose the output format.
Step 4. Choose JPG here if your destination accepts it.
1. Format chooses the kind of file to save.
Step 5. Use Original when you need all the pixels. For a smaller whole-frame copy, choose Dimensions; these example bounds are 960 × 640.
1. Original keeps dimensions; Dimensions fits the image inside pixel bounds.
2. Width and Height set pixel bounds; Keep aspect ratio avoids stretching.

With the settings ready, make and inspect one copy before you add more images.

Step 1. Close Settings when your choices are ready.
1. Settings closes the controls on a phone.
Step 2. Press Process 1 image to make the copy.
1. Process 1 image applies your settings.
Step 3. Check the finished dimensions, size and preview before adding more files. Download saves the copy; keep your original for later edits.
1. Check the result’s size and dimensions.
2. Download saves this finished image.

If the photo finishes converting and then won't download on a phone, our large-download guide covers that separate problem. A download error doesn't establish an image conversion limit.

Need to resize a very large image?

Image Space Saver

How we measured

Date: October 8, 2026. Browser: Chrome 155.0.8059.39 and Firefox 155.0. Device: AMD Ryzen 9 5950X desktop, Windows 11 Pro.

FluffyBench’s WebP converter converted the full photo to WebP at the browser default. Separate browser API timings compare WebP at quality 92, WebP at quality 80, JPEG at quality 92. The worker comparison used canvas.toBlob on the main thread and OffscreenCanvas.convertToBlob in a worker. The quality and format comparisons time encoding only and do not compare how the results look.

One 12,000 × 9,000 JPEG, 18,888,121 bytes and Exif orientation 6, labeled 108 MP; two centered crops labeled 24 MP and 48 MP; one generated 12,240 × 16,320 JPEG of 8,602,261 bytes; and one phone reproduction with a photo labeled 108 MP.

Recorded times are milliseconds; charts display seconds rounded to two decimals. Times are medians of three runs unless a single cell is named. File sizes use decimal KB and MB with exact bytes in accessible text.

The full-grid byte estimate is calculated at four bytes per pixel position and excludes other browser memory. The crop-boundary drawing uses the recorded dimensions; it is a schematic, not the source photograph. Walkthrough screenshots use a separate lily photo to illustrate the current Image Space Saver UI, not to measure conversion time.

The times describe these browsers, this desktop and these images. They do not establish a device capacity or a timing rule for other inputs.

The stage medians cover decode, draw, encode and total time at the converter's own stage boundaries in three fresh-page runs per browser. Crop, quality, format and worker comparisons time browser APIs separately on the same machine and date.

In a separate WebP quality-92 API comparison, moving the encode to a background worker barely changed the recorded encoding time; responsiveness was not measured.

FluffyBench’s WebP converter refuses inputs above 268,435,456 pixels or a side longer than 32,768 pixels. Passing these code cutoffs does not establish that a device has enough memory.

The 199,756,800-pixel generated-image runs took place on October 9, 2026, one run per cell. WebP encoding accounted for most of Chrome's recorded converter time. Firefox's raw wall times included an identified click delay, so its encoding times are the usable comparison.

The phone reproduction took place on October 7, 2026 using a OnePlus 6T running Android 10, in Firefox 156. The download stopped after a 30-second pause, with 185.5 KB received. It measured no phone conversion time or size threshold, and the record shows no completed encode.