Our compressor accepts a batch, starts processing immediately, and returns either a smaller encoding or the original file. That last option matters: an image that has already been optimized should not become larger because someone ran it through another tool.

The implementation is plain JavaScript: canvas encoders, a bounded Web Worker pool, and JSZip for batch downloads. The same compression engine runs in a website and a Manifest V3 Chrome extension. Here are the decisions and failure cases behind it.

1. Keep the compression path on the device

For this utility, a server would add an upload, a second copy of the image, and another failure boundary. Browser APIs can already decode common image formats and encode a canvas. We keep the selected files as File and Blob objects and generate downloads from their results.

Once the application and its bundled assets have loaded, the JPG, PNG, and WebP compression path does not need a network request. That is a runtime property, not a promise that an uncached page can always be opened offline.

There are two exceptions worth separating. The website loads a pinned HEIC decoder when someone first imports HEIC; that request fetches decoder code, not the image. The extension also has a separate, explicit AI editing action that passes the selected image to an external editor. Neither action is part of ordinary local compression. The extension does not bundle the HEIC decoder.

Keeping those boundaries explicit made the privacy explanation easier to check against the code.

2. Treat an encoding as a candidate

We decode the input with createImageBitmap, draw it at the requested dimensions, and ask a canvas encoder for an output Blob. The core prefers OffscreenCanvas; its alternative creates an HTML canvas. Encoding uses convertToBlob when available and toBlob otherwise.

The automatic format policy is small enough to read in full:

function candidateTypes(srcType, alpha, format) {
  if (format && format !== 'auto') return [format];
  if (srcType === 'image/png') return alpha ? ['image/webp'] : ['image/webp', 'image/jpeg'];
  if (srcType === 'image/webp') return ['image/webp'];
  return ['image/jpeg'];
}

An opaque PNG gets WebP and JPEG candidates, and the smaller encoded Blob wins. A transparent PNG gets a WebP candidate instead of silently flattening its background. WebP stays WebP in automatic mode; JPEG follows the JPEG path. An explicitly selected output format overrides this candidate list.

PNG output is also available explicitly, but a JPEG-style quality parameter is not a useful control for its lossless encoder. We do not pretend that one quality slider has equivalent behavior across formats.

Before choosing candidates, the core checks every alpha value in relevant inputs. Sampling looked attractive until a fixture with one transparent pixel exposed the problem: missing that pixel could send a transparent image down the opaque JPEG path. The complete scan costs work, but it gives the format policy reliable information.

3. Compare against the real original

The size guarantee belongs after candidate selection. It must also apply after resizing, forced conversion, and preprocessing.

This is the actual return guard in the engine:

if (best.blob.size >= original.size) {
  return { blob: original, type: originalType, width: originalWidth, height: originalHeight, kept: true,
    constraintsSkipped: !!(resized || forced || original !== file),
    targetMet: !(opts.targetKB > 0) || original.size <= opts.targetKB * 1024 };
}

Equal size counts as a reason to keep the original too. The result describes the file that will actually be downloaded, including its original dimensions and type.

This choice has a visible consequence. If a requested JPEG conversion or resize would produce more bytes, the user receives the original and an “Original kept” explanation. The tool cannot promise both “always convert to this format” and “never increase file size” for every input. We give the size rule priority and expose skipped constraints.

HEIC needed an additional correction. Its decoded JPEG is an intermediate, not the user's original. The wrapper passes the original HEIC file into the engine, so the final comparison uses those original bytes. Comparing only with the decoded JPEG would make the displayed savings misleading.

4. Bound the workers, then package the results

Each worker receives a file, options, and a job identifier. It returns either the result or an error carrying that identifier. The UI owns the queue and file rows.

The pool size is deliberately bounded:

var n = Math.min(4, Math.max(2, (navigator.hardwareConcurrency || 4) - 1));
try { for (var i = 0; i < n; i++) this.pool.push({ w: new Worker(this.workerUrl), busy: false }); }
catch (e) { this.pool = []; }

That creates two to four workers rather than one per selected file. A free slot takes the next queued item. Completion updates its row, releases the slot, and pumps the queue again. When workers are unavailable, or the app is opened through file://, the code uses the main-thread path instead.

Moving pixel work off the UI thread helps responsiveness; it does not remove memory limits. A compressed file can decode into a much larger pixel buffer, and transparency checks read those pixels. Large batches still depend on the device.

Completed results are collected into a ZIP with the bundled JSZip library. Duplicate output names receive suffixes rather than overwriting each other. A single result downloads directly. A failed file remains an error row, instead of becoming a zero-byte “successful” download.

5. Reuse the engine in a Chrome extension

The extension opens the same compressor UI in a tab. Its right-click compression action passes the selected image URL to that tab; it does not compress inside the service worker.

Reading a remote image requires more care than reading a local File. The compression page initially shows an internal icon instead of loading the remote thumbnail immediately. Only after the user clicks “Compress it” does it request access to the source site and fetch the image. A denied request leaves an explanation and a manual-file alternative.

The current MV3 package also declares scripting and a fixed host permission for www.wery.ai. Those support the separate “Edit photo with AI” action, which places the chosen image into the editor's file input. They are not a hidden requirement of local canvas compression. Ordinary AI links only navigate; the explicit right-click editing action carries the image.

Theme selection is independent of both paths. Auto follows the browser's color preference; Light and Dark set an explicit document theme. A local preference survives refresh. The website continues to follow the browser automatically.

6. Test the promise, not just a nice photograph

Our project notes record an earlier five-image website run with a 56% reduction in combined file size. That is one input set, not a general compression ratio or a speed benchmark.

The screenshot below shows a different five-image batch with an 80% aggregate reduction. Its numbers should not be substituted for the earlier run.

For regression checks, the more useful inputs were the awkward ones. A 70-byte PNG returned unchanged. A transparent PNG with a single transparent pixel retained that pixel. A 24,163-byte HEIC returned as the original when the candidate was larger. An 85-byte PNG forced toward JPEG with smaller dimensions also returned its original bytes and dimensions.

Those cases catch failures that a large, easily compressed photo misses. We also unpacked the downloaded ZIP and compared retained originals byte for byte.

The comparison viewer helps inspect visual tradeoffs. It is not evidence that a lossy re-encode is pixel-identical to its input.

7. Leave the limits visible

A target size is an attempt, not a guarantee. For JPEG and WebP targets, the implementation tries seven quality values per round and up to six rounds of progressively smaller dimensions. If that bounded search still misses the requested size, the result says “Target not reached.” The final original-size guard still applies.

Canvas re-encoding is also not an archival, metadata-preserving operation. Animated input becomes a still image, supported encoders depend on the browser, and large canvases can run into device limits. We keep error states and retained-original states distinct from successful conversions.

The most useful design decision was making the final byte comparison the authority. Format heuristics can improve, and encoders can change, while the downloaded result still obeys the same rule.

The source code is on GitHub, and the browser version is available here.

I work on WeryAI, where we also build AI photo tools such as the AI photo editor.

This article was prepared with AI assistance and checked against the implementation and the project's recorded tests.