Privacy whitepaper

PixelProof treats upload avoidance as architecture, not copy.

This page documents the technical boundary behind the no-upload claim: what runs locally, what browser storage is used, what network traffic still exists, and how a user or security reviewer can verify the behavior.

Run upload checks →Read compliance notes →

File and Blob APIs

Selected images are read from the user's device into browser memory. Exports are created as local Blob objects and downloaded by the browser.

Canvas, workers, and client libraries

Resize, compression, conversion, and PDF workflows use browser execution rather than a server-side image processing queue.

Local handoff storage

When a user continues from one tool to another, the temporary file handoff is stored in this browser's IndexedDB and cleared after the receiving tool loads it.

Network boundary

No upload does not mean no network.

The app shell, JavaScript bundles, fonts, images, and static assets are still downloaded over the network.
Production analytics can record route-level usage, but image pixels and selected file contents are not part of that event model.
Platform source links leave the site only when a user explicitly opens them.
No privacy claim here replaces a production audit, SOC 2 report, DPA, or customer-specific security review.
Verification steps

How to test the claim yourself.

  1. 1Open the page, then open DevTools and clear the Network panel after the app shell has loaded.
  2. 2Choose a local test image and run a resize, compression, conversion, PDF, or upload check workflow.
  3. 3Look for file-upload requests such as POST bodies, multipart form-data, or requests whose payload size matches the source image.
  4. 4Confirm outputs are created as blob: URLs or local downloads instead of server-hosted processed files.
  5. 5For highly sensitive files, load the app first, disconnect the network, then run the edit session offline.