How to verify that a browser file tool does not upload your file

Three distinctions to make first

Actual requests after compression and download on the production site

On October 14, 2026 the operator performed image compression and download on the production site, then inspected Chrome DevTools requests and three payloads. These are crops of the supplied actual screenshots, not illustrated screens or locally simulated telemetry.

The recorded list contained 15 entries. Three POSTs to /api/tool-usage returned 204; their events were start, success and download. Reviewed payloads showed tool, counts, language, source classification and anonymous identifiers; success also included completion count, duration and error code. No filename or image data appeared in those three payloads.

The PNG and WebP GETs read temporary blob:https://toolit.kr/ addresses, not server upload endpoints. The other ten GETs had McAfee-related asset names. Their full origins were not inspected, so they are not classified as Toolit traffic.

Network Size is not a measurement of request-body bytes, and the 3.7MB resources total is not uploaded image data. The approximately 2101ms completion duration describes this recorded work interval, not a device-speed benchmark. The screenshots do not establish the input filename or exact output bytes.

No source-image upload request was observed in this captured compression/download interval. This does not cover requests before/after recording, other tools, browsers, extensions or all GA4/ad traffic. It is one operator run marked internalTest true.

Public images are pixel-preserving crops. Anonymous IDs and unnecessary extension URLs were excluded without repainting requests or text. The JSON is a manual screenshot transcription, not HAR or a raw HTTP log.

[
  {
    "tool": "image-compressor",
    "fileCount": 1,
    "internalTest": true,
    "language": "ko",
    "source": "direct",
    "event": "start"
  },
  {
    "tool": "image-compressor",
    "fileCount": 1,
    "internalTest": true,
    "language": "ko",
    "source": "direct",
    "event": "success",
    "completedCount": 1,
    "durationMs": 2101.10000143051,
    "errorCode": "",
    "failedPosition": 0
  },
  {
    "tool": "image-compressor",
    "fileCount": 1,
    "internalTest": true,
    "language": "ko",
    "source": "direct",
    "event": "download"
  }
]

The current code separates file processing from telemetry

An October 14 source review confirms that the image compressor reads an image with createImageBitmap, encodes on Canvas and creates a temporary result URL from a Blob. Tool telemetry is a separate path.

Custom tool telemetry can send JSON to /api/tool-usage. Its call sites pass tool type, state, counts and processing time, not the source File or result Blob. Local development skips telemetry, so absent localhost requests do not prove absent production requests.

GA4 now uses Google’s basic tag with settings controlled in Analytics. Page URLs, titles, referral data and configured automatic measurements are separate from custom tool telemetry and advertising traffic. A request is not automatically a file upload.

The call sequence below is source-review evidence, separate from the operator Network capture above. The August 20 observation remains historical. Neither the new screenshots nor source review verify all GA4 and ad traffic.

decodeImageInput(selected File)
  → createImageBitmap(...)
  → Canvas.drawImage(...)
  → Canvas.toBlob(...)
  → URL.createObjectURL(output.blob)

beginToolUsage / finishToolUsage
  → metadata JSON (not File / result Blob)
  → /api/tool-usage
  → skipped on local-development addresses

• Reviewed files: components/image-compressor.tsx, lib/image-input.ts, lib/tool-usage.ts
• Baseline: production code d42f242 with the Google-basic GA4 tag. Source review and Network screenshots are distinct evidence.

What local browser processing means

A web page can read a user-selected File object—the browser's representation of that file—and create a result with features such as Canvas, WebAssembly, or a PDF library. In plain terms, the current device can perform the computation without handing the file to a processing server. Source and intermediate data remain in browser memory, while the finished file is downloaded from a temporary object URL.

This removes the upload wait and avoids storing file contents on the operator’s server. The tradeoff is that large files consume the visitor’s memory and CPU, so a tab can slow down or close on lower-memory devices.

Does every Network entry mean an upload?

No. A page may fetch CSS, fonts, processing engines, anonymous usage analytics, or enabled advertising. The useful question is not whether any connection occurred, but whether the selected file content was included in a request.

Uploads often leave clues such as POST or PUT methods (ways for the browser to send data), multipart/form-data bodies (a common file-upload format), and transferred sizes close to the source file. Implementations vary, so inspect both the request contents and its size rather than relying on one clue.

• Check whether the method is POST, PUT, or PATCH.
• Compare Transferred and Resource Size with the selected file size.
• Look for a file name, multipart/form-data, or recognizable file content in Payload.
• Compare requests created at operation start with those created just before download.

What an offline test can and cannot prove

If an operation still finishes after the page and processing engine have loaded and Network is switched to Offline, that is strong evidence that the core computation does not depend on a remote response. Do not refresh after going offline, because the browser may then be unable to reload the page assets themselves.

Offline success does not verify an entire privacy policy. When online, a site may still send anonymous analytics, advertising requests, or error reports that do not contain file contents. Review both the offline behavior and the online Network log.

Live browser check on August 20, 2026

In Chrome, we selected a 1,741,024-byte PNG at 1536×1024 and ran a 500KB-target WEBP compression. The result was 172.9KB at the original 1536×1024 dimensions and a reported quality of 95%.

From file selection through result generation, the local development server log showed only the initial page GET and no file-upload request. The implementation also reads the file with createImageBitmap, re-encodes it on a Canvas, and creates the result URL with URL.createObjectURL rather than sending the file or output Blob to a server.

This check is scoped to Chrome and the image-compression workflow observed on August 20, 2026. Anonymous production analytics may create a separate request, but its payload is limited to the tool, outcome, file count, and bucketed processing time—not a file name or file contents.

Common verification mistakes

Seeing a file name in the interface does not prove an upload. Browsers make the selected name and size available to the page locally. The reverse is also true: binary data may be sent without showing a file name in the interface, which is why the Network log matters.

You do not need a sensitive document for the test. Use a small image you created or a public sample, and give it a distinctive temporary name so traces are easier to spot in a request body.