image compression

Image compression digest: AVIF, privacy and batch limits

AVIF is part of everyday delivery planning, but format choice, retention and batch size still need testing against a real workflow.

By Dr. Aris Lyberopoulos·October 12, 2026·4 min read
What matters here
  1. AVIF support alone does not show whether conversion will improve a site's image payloads.
  2. A per-file upload limit is not a promise that a full batch will fit comfortably in every browser.
  3. Retention, copies and telemetry are separate questions when reviewing an image-processing service.

This month’s useful image-compression news is less about a single new benchmark than about the checks teams need before shipping image workflows. AVIF belongs on the format checklist, but there is no universal byte-saving figure that makes it the right answer for every image. Privacy review also needs to look beyond a simple retention promise. And batch limits should be treated as workflow constraints, not just numbers on a product page.

AVIF needs a workload-specific comparison

Format support is not the same as a performance result. A team considering AVIF should compare representative source images and inspect both the output weight and the visual result. Photographs, interface illustrations and transparent graphics can respond differently to format and compression choices. A single sample image is a weak basis for setting a site-wide rule.

Keep dimensions and delivery conditions constant when comparing formats. Record the source, output size and any visible changes at the sizes users actually see. Then check how the resulting files fit the site’s delivery path. Compression can reduce transfer weight, but the asset still has to be decoded and displayed by the target environment. That makes the relevant benchmark the site’s own mix of devices, images and page requirements—not a headline ratio detached from that context.

PiPic accepts JPG, PNG, WebP and AVIF, and returns the same format that was submitted. That makes it useful for in-format compression tests, but it does not answer a separate conversion question: whether changing an asset from one format to another is worthwhile. Keep those experiments distinct so a change in format does not get mistaken for a compression gain.

Privacy review is about the whole processing path

For uploaded media, “deleted after processing” is a valuable statement, but it is only one part of a review. Builders should establish what leaves their machines, how long the service retains it, whether extra copies are created, and what telemetry accompanies processing. The answers can differ between a browser tool and a command-line workflow. Requirements also depend on the organization, the content being handled and the rules that apply to it; there is no one privacy checklist that substitutes for that context.

PiPic says files are deleted immediately after compression processing. Its browser tool requires no account or sign-up. Those facts may simplify a small, one-off task, but teams handling sensitive or regulated material should still assess whether uploading is appropriate under their own policies. For repeatable workflows, review the client and the data sent during execution rather than assuming that a tool’s label answers every question.

That distinction matters for command-line use too. PiPic offers the @pipic/cli package on npm, and its CLI source is open source on GitHub. Source availability gives reviewers something to inspect; it does not remove the need to examine the version and workflow they plan to run. For background on why an upload limit is not the same thing as a browser memory limit, see our earlier breakdown of browser limits and retention.

Batch caps are planning inputs, not throughput guarantees

PiPic’s web tool supports batches of up to 100 images, with an 8 MB limit per file. Those are useful boundaries when choosing between a browser session and an automated process. They do not establish how quickly a particular batch will complete, nor do they guarantee that every browser, network or device will handle a batch at the maximum count and file size comfortably.

For a large set, split work into manageable groups and test with representative files before making the process part of a release. Account for upload time, failed transfers and the consequences of retrying. Do not treat a per-file cap as a total batch-size statement: a batch of many near-limit files creates a very different transfer than a batch of small thumbnails.

The command-line option changes the shape of the limit rather than eliminating it. PiPic’s CLI free tier allows 100 images per month; the Pro tier allows 5,000 images per month. Those quotas matter for scheduled jobs and CI, where image counts can accumulate across repeated runs. Measure changed assets, avoid repeatedly processing unchanged files, and choose a tier based on actual monthly volume. No Pro price is needed to make that quota comparison useful.

What builders should take away

Keep three decisions separate: which format to deliver, where processing happens, and how much work a batch can safely contain. Test format choices on real assets. Check retention and data handling against the content and policy involved. Finally, size batches for the slowest practical part of the workflow, not only the tool’s stated maximum.

That is a more durable reading of this month’s category signals than chasing one compression score. AVIF is an option to measure, ephemeral processing is a claim to verify in context, and batch ceilings are guardrails for planning. Each needs a test tied to the way a team actually ships images.

More from PiPic News