Image compression digest: browser limits, WASM and retention

Image compression decisions tend to get reduced to one number: the upload limit. But a file-size cap is not a reliable measure of what a browser can process, and it says little about where the image goes or how long it stays there. Those distinctions matter as teams handle larger batches, move compression into build pipelines, and tighten expectations for data retention.

An 8 MB file is not an 8 MB workload

There is no universal 8 MB browser-memory boundary. That figure is a product limit, not a web standard. A compressed image is stored in a compact form; an application generally has to decode it into pixels to manipulate or recompress it. A 4,000-by-3,000 image represented at four bytes per pixel takes about 48 MB for the decoded pixel data alone. Temporary copies and other browser work can add to that footprint.

So the practical question is not only “How large is the upload?” It is also how many pixels it contains, how many images are processed at once, and what memory is available on the device. A batch of modest files can still put pressure on a low-memory phone or a busy browser tab. Test with the largest dimensions and batch sizes your users actually provide, not just a representative small image.

WebAssembly gives developers a way to run compiled compression code in the browser. That can reduce the need to send source images to a remote service, but it does not make decoding free or eliminate memory limits. A client-side pipeline still has to manage decoded pixels, worker memory, and responsiveness. Moving work into a worker can help keep an interface responsive; it does not make the underlying workload smaller.

Serverless is a deployment choice, not a privacy guarantee

Serverless image pipelines can be convenient for web apps: a function receives an upload, transforms it, and returns a result. They also make operational details easy to overlook. Request-size ceilings, execution time, cold starts, temporary storage, and concurrency all affect whether a batch works reliably. A pipeline that succeeds for a single avatar may behave differently when a user submits dozens of high-resolution files.

Build those limits into the design. Set a clear maximum file size and batch size, handle failures without losing originals, and avoid keeping temporary files longer than necessary. If a workflow needs repeatable output, test it against the same representative files in local development and CI. “Serverless” describes how code runs; it does not specify the limits or retention behavior of the service around it.

Retention claims need precise language

Zero trust is not a synonym for “we delete uploads.” It is a broader way of limiting access and verifying requests. For image processing, builders should ask more narrowly: does the image stay on the device, is it uploaded, how long is it retained, and are copies created in logs or temporary storage? An immediate-deletion policy can reduce exposure, but it is different from local-only processing.

PiPic’s browser tool takes uploads, supports JPG, PNG, WebP, and AVIF, and says images are deleted immediately after processing. It accepts up to 100 images per batch, with an 8 MB limit per image, and returns compressed batches as a zip. The free browser tool needs no account and adds no watermark. Those are useful, concrete boundaries; they should not be mistaken for an on-device workflow.

For developers, PiPic also offers an open-source CLI, @pipic/cli, with a free tier of 100 images per month and a Pro tier of 5,000 images per month. The quotas are image counts, so teams should check how their own asset volume fits before wiring a tool into recurring automation. Questions about what a CLI sends and retains deserve the same scrutiny as questions about a browser upload. Our earlier review of telemetry and network risk in command-line image tools covers the audit questions worth putting on that checklist.

What to measure in the next compression pass

For web performance, measure the output that reaches the page: transferred bytes, image dimensions, format, and the effect on loading. Smaller payloads can help, but a compression target should not silently change the asset’s format or break a URL-dependent workflow. When a pipeline retains the original format, it may fit systems that assume existing extensions; the right choice depends on the site’s delivery path.

Keep originals until the compressed output has been checked, especially when processing a large batch or replacing production assets. Track failures as well as average savings. A tool that produces a good result on most files but skips one critical image can create more work than a slightly slower pipeline with clear errors.

The category’s useful shift is less about one headline file-size ceiling than about treating limits as separate engineering decisions. Upload caps, decoded-memory pressure, execution time, and retention describe different risks. Test each one directly, and choose browser, serverless, or CLI processing based on where the work and the data need to live.