Privacy architecture

What private, browser-side image compression actually means

Follow the media path from browser File object to local Worker and download Blob, and understand the limits of a local-processing claim.

‘No upload’ should describe a verifiable data path, not just a marketing phrase. In a browser-side compressor, selected image bytes move through browser memory, a local encoder, and a local download object without entering the application backend.

The local media path

When a visitor chooses a file, the browser gives the page a File object. Ziply screens supported image headers, reads dimensions, and passes local data to a Worker. The Worker uses the available Wasm or browser codec path and returns encoded bytes. The page creates a Blob URL for comparison and download.

Those Blob URLs identify data held by the browser; they are not public web addresses. Ziply revokes them when items are removed or the page is left. The application’s service worker caches application assets, not selected images or generated outputs.

What can still use the network

The page itself, encoder assets, and future updates arrive over the network unless already cached. Premium validation and Stripe billing use the API, and aggregate telemetry can be sent after an explicit opt-in. Those requests are designed not to contain selected files, filenames, previews, hashes, or exact media byte counts.

Learn articles can contain a manually placed Google ad unit when advertising is enabled. Compressor routes do not mount those units. Premium visitors do not load Ziply ad units, and eligible advertising remains subject to the configured consent manager.

How to verify the claim

Open browser developer tools, select the Network panel, and process a uniquely named test image. Inspect request URLs, methods, sizes, and request bodies. Image bytes should not appear in an API request. Repeat after enabling and disabling optional telemetry so the difference is observable.

Repository checks can complement browser inspection by rejecting media-bearing API routes and multipart endpoints. Deployment review should also verify that no proxy, monitoring tool, or newly added integration broadens the backend surface without an explicit architecture decision.

  • Use a synthetic test image rather than confidential material during verification.
  • Filter network requests by the test filename and by the API hostname.
  • Check both normal processing and error paths.
  • Retest the exact production artifact after meaningful dependency or infrastructure changes.

The honest limit of browser privacy

A web application cannot protect a file from a malicious extension, compromised browser, infected operating system, or altered deployment. It also cannot prove what an unrelated screen-capture or accessibility tool does. Local processing narrows the intended data flow; it does not make the device invulnerable.

Ziply’s commitment is therefore specific: the supplied application does not intentionally transmit selected image content to its API or advertising providers, and the media backend surface is intentionally absent. That boundary is more useful when it remains testable and narrowly worded.