Bulk Image Conversion Test: Why Files Run One at a Time

Successful converted files are placed in an images folder. The JSON report records the chosen settings, input and output sizes, dimensions, elapsed time and any failure message.

A browser holds decoded pixels as well as compressed files. Thirty files and a 250 MiB input cap keep the free tool useful without implying that every device can safely process an unlimited folder.

A small compressed file can expand into a large RGBA pixel surface. A 6000 × 4000 image needs about 96 million bytes for one four-channel surface before the browser holds source bytes, preview, output and temporary codec buffers.

Starting many conversions at once multiplies those surfaces and can terminate a mobile tab. Sequential processing trades some speed for a predictable upper bound.

The queue contained 29 controlled valid images and one deliberately invalid file. All valid files used the same output settings. Instrumentation recorded active conversion count, per-file result and final manifest rows.

The invalid item was placed where it could prove failure isolation rather than merely failing after all successful work. No file bytes were sent to an upload endpoint.

Maximum active conversions remained one. All 29 valid items reached the ZIP, the invalid input produced one clear failure, the queue continued and progress reached completion. The manifest contained one row for every selected input.

This is a functional and resource-policy test, not a speed benchmark. Elapsed time depends on dimensions, codec, processor, available memory and browser version.

The generated archive began with the expected ZIP signature, used sanitized paths and included successful images plus a JSON report. A filename attempting directory traversal could not create a ../ path in the archive.

The manifest records settings, dimensions, input and output bytes, elapsed time and failures so a user does not have to guess which files were omitted.

The tool caps the batch at 30 files and 250 MiB of compressed input, with per-file size, dimension and megapixel guards. These limits cannot guarantee every old phone will succeed, but they block obvious abuse and accidental overload.

One-at-a-time processing also keeps error recovery simple. The user can identify the failed file without losing successful outputs or restarting a parallel pool.

Use representative small, medium and large files from the target workflow and include one invalid input. Record device, browser, total compressed bytes, dimensions, output settings, elapsed time and whether the tab stayed responsive.

Increase limits only from measured evidence. A desktop success alone is not enough for a mobile-first public tool, and a lower cap is preferable to an impressive number that crashes ordinary devices.

Because images stay local, monitoring should not collect filenames, pixels, metadata, GPS or hashes. It can safely count anonymous error codes, tool version, broad stage and bounded numeric context such as attempted batch size.

That privacy-preserving telemetry can show whether users frequently hit memory or format limits without turning the diagnostic system into a file log. Session diagnostics remain local unless a user chooses to download and share them.