Verify video stays on this device

LocalVideoZip compresses MP4, WebM, and MOV in the browser with ffmpeg.wasm. This page is the check you can run yourself: which network calls are normal, and which calls would mean the media file left the tab. The compressor is on the home page. The short policy is the privacy policy. The copyright rules are the terms. Publisher context is on about.

What you are proving

You are proving that compression does not upload the media file. You are not proving that nothing on your computer can see the bytes. A browser extension, malware, or a recorder you installed can still read a tab. This site does not receive the file, and it does not claim to block other software on the device. Files never leave this device through this page.

If Network shows a POST or PUT of your video, stop using that session and write to contact@localvideozip.pages.dev with the page URL and what you saw — without attaching the file. That would not match how this tool is built.

Steps in DevTools

  1. Open the compressor. Use a short clip you are allowed to test with, not a sensitive recording, the first time you learn the panel.
  2. Open DevTools → Network. In Chrome that panel is documented as the Network panel. In Firefox it is the Network Monitor. Enable “Preserve log” so a reload does not wipe the list.
  3. Reload the page once and let the first requests finish. You should see same-origin GETs for the document, /assets/styles.css, /assets/limits.js, /assets/tool.js, /assets/vendor/ffmpeg/ffmpeg.js, and the favicon.
  4. Drop the video file. Wait until the preview or an error appears. Sort or scan the new rows. There should be no request whose body is that file, and no POST or PUT of the media to this host or any other host.
  5. Pick a preset and press compress. The first run loads ffmpeg into the tab. Expect a GET of ffmpeg-core.js from this host, then a GET of the pinned ffmpeg-core.wasm from cdn.jsdelivr.net (Cloudflare Pages rejects files over 25 MiB, so the ~30 MB wasm is not self-hosted). Open that wasm response: it is the encoder binary, not your video. The request body is empty.
  6. Download the compressed MP4. The link is a blob: URL created in the tab. The browser is not fetching those bytes from our server.

Expected requests

Requests that should not appear

Why the file can stay in the tab

The drop area is a file input. The File API lets the page read a file the user chose. It does not give the page a path it can upload on its own later. ffmpeg.wasm reads those bytes in WebAssembly memory in this tab, writes a new MP4, and the download button points at an object URL from URL.createObjectURL. When you close the tab, that buffer goes with it. We have no project library to reopen.

Input over ~200 MB or longer than 180 seconds is refused before encode. Output is H.264 + AAC MP4 (best-effort). Exotic source codecs may fail locally — that error is not an upload.

Publisher, contact, and policy pages

These pages stay on the existing URLs. They are how you learn who publishes the tool and how to reach us:

This experiment does not run advertising scripts today. Response headers set script-src 'self' (plus blob: and wasm-unsafe-eval for encode). If that ever changes, privacy and about would need an honest update first.

Where to go next

Questions about this wording, email contact@localvideozip.pages.dev. Do not attach the video. We cannot accept the file, and we do not want private footage in a mailbox.

Sources

FAQ

How do I prove this compressor does not upload my file?

Open DevTools → Network, drop a local file, and compress. You should see same-origin page assets, same-origin ffmpeg JS, and one jsDelivr GET for the wasm binary. You should not see a POST or PUT of the media. Downloads use a blob URL created in the tab.

Is the jsDelivr wasm fetch an upload of my video?

No. It is a GET of the pinned ffmpeg-core.wasm package. The response is encoder code. Your samples are not in that request. Encoding then runs in the tab.

What is a blob download?

After encode, the download link points at a blob: URL made with URL.createObjectURL on a Blob built in the page. The browser saves those bytes from memory. It does not download them from our server.

Which network requests are a problem?

A problem is any request that sends the video file, calls a third-party compress API, or fetches a remote media address. Static assets, the ffmpeg JS, the pinned wasm GET, and an optional Cloudflare Web Analytics beacon are not the video upload.

Can the page fetch a YouTube or stream URL?

No. There is no URL field and no stream ripper. You can only choose a file already on the device, and the terms require that you have the rights to compress it.

Where do I report a Network result that looks wrong?

Email contact@localvideozip.pages.dev with the page URL and what you saw in DevTools. Do not attach the video. Start from this trust page and the privacy wording so we can compare claims to behavior.