How We Verify No-Upload Claims

Privacy pages can be useful, but they are still claims. If a tool says "your files are not uploaded", that statement should survive a network inspection during a real job, not just a marketing review.

We treat no-upload language as a route question: what happens when a user selects a file, runs the operation, and downloads the result?

We use a small repeatable checklist rather than a one-off guess. The goal is to make the route visible enough that another reviewer could repeat the same test later.

• Load the tool normally and open the Network panel before selecting any file.
• Run one realistic file operation rather than an empty or toy interaction.
• Filter for fetch and XHR traffic, then inspect request size and payload behaviour.
• Repeat the operation after the page is loaded and connectivity is removed where possible.

The obvious red flag is file data moving to a remote endpoint during the job. There are softer red flags too: opaque route switching, optional features that quietly invoke remote services, and upload-dependent fallbacks that appear only on certain file types.

• request payloads that scale with the uploaded file
• remote endpoints called only when the actual processing step starts
• a workflow that stops working as soon as connectivity is removed
• mixed local and remote routes that are hard for ordinary users to recognise

Network testing is strong evidence, but it is not the whole compliance story. It tells you whether document bytes appear to leave the browser during the tested route. It does not replace product review, legal review, or environment-specific governance.

The practical standard is not perfection. It is whether the route is clear enough, repeatable enough, and observable enough to trust in ordinary operations.