Batch-editing photos without uploading them: what we measured

Eighteen NASA photos, 68.5 MB between them and up to 54 megapixels each, went through three steps (resize to 2048 pixels, add a name in the corner, compress) in 31 seconds on a laptop and came out as 6.01 MB of JPGs. None of them left the machine. Watermarking the same eighteen at full size took 55 seconds and produced 76 MB, more than we started with.

We ran these tests on 27 September 2026 through our Workflow tool, which chains the site’s free tools and runs them in the browser, one file at a time. Each test ran twice on the same Mac (Apple M5 Max): in Chrome 153, and in Safari’s engine (WebKit 26.6) set up like an iPhone on iOS 17, with its screen size and its limit on how big a canvas can be. That is not a real phone, and we say below what that leaves out. The photos are public-domain astronaut portraits and crew shots from NASA’s image library; the phone photos are public samples from two iPhones and a Nokia.

Resize first, then add to the picture

The order of the steps did most of the work. A 45-megapixel photo of 17 MB came back at 0.39 MB after the three-step chain, and at 17.25 MB when only watermarked, because a watermark means saving the whole picture again at its full size. Shrinking it first also made every later step faster: the slowest photo went from 11.5 seconds to 2.3.

We’d put resizing first in almost any batch that ends up on a website, in an email or in a chat, and leave full size only for photos that are going to be printed. Our watermark in bulk page opens the Workflow tool with this three-step chain already set.

A PDF of phone photos is bigger than the photos

Five public phone photos (two iPhones, two Nokia .heif files and a small test image), 6.63 MB in all, went into one PDF with a photo on each A4 page. Without a compress step the PDF was bigger than the photos, because each picture is saved inside it as a high-quality JPG, and JPG needs more bytes than HEIC for the same look.

Recommended keeps pictures at 150 dots per inch on the page, about 1,160 pixels across a photo on A4, which reads well on a screen. Light keeps about 1,700 and suits printing. The HEIC to PDF page opens the Workflow tool with the Recommended chain set.

One bad file doesn’t stop the batch

We cut a JPG short after its first 6 KB and put it in a batch of four. It stopped at the first step with “This file could not be opened as an image”; the other three photos finished in 5.6 seconds and downloaded together, and the results listed which file stopped, at which step and why. A JPG whose metadata block is damaged (the corrupted.jpg sample from exif-samples) went through normally, since only the picture has to be readable.

Phones: canvases and memory

Every step that changes pixels draws them on a canvas, and Safari on iPhone and iPad caps how big a canvas can be. Until iOS 17 the cap was 4096 by 4096, 16.7 megapixels, smaller than the 24-megapixel photos an iPhone 15 saves by default. WebKit raised it to 8192 by 8192 in March 2024 because the memory limit on iOS had been raised. Our tools read a big photo in strips no taller than the old cap, so a photo over it still opens on an older iPhone; in the runs above, which used the iOS 17 cap, none of the 18 photos hit it.

Memory is the other limit. Safari closes a tab that uses too much, and a phone has far less to give than a laptop. The Workflow tool handles one file at a time and lets go of it before the next, so a long batch takes longer rather than needing more memory, but a single very large photo is still the step most likely to fail on a phone. Resizing first helps there too.