How AetherCut handles your files

Does AetherCut upload my video when I open it?

No. The browser creates a File object and a blob URL that stays in browser memory, so AetherCut can load the video locally for playback, scrubbing, and seeking without sending the file anywhere.

When you drag a video onto the editor (or click the upload area), the browser fires a change event with a File object. That object is a handle to bytes the browser has read off your disk. It is a JavaScript reference. Nothing leaves the page.

AetherCut calls URL.createObjectURL(file). The browser returns a blob: URL — a pointer to those bytes, still living entirely in the browser's memory. We assign that URL to a hidden <video> element so the editor can play, scrub, and seek through your footage.

Does AetherCut upload the file again when I cut?

No. When you cut, AetherCut seeks the hidden video to a timestamp and copies a frame into a canvas. It works from frames already available in browser memory, not by uploading or rereading the original file.

When you make a cut, AetherCut doesn't read the original file again. It seeks the hidden video to a timestamp, copies one frame into a <canvas> element, and draws the timeline thumbnails from that canvas. The MOV / MP4 / MKV bytes on your disk are never re-uploaded — they're already in browser memory.

Where does AetherCut export the finished video?

AetherCut encodes the export inside the browser using WebCodecs or MediaRecorder, then hands the output blob to a download link. The browser saves the new file to your local Downloads folder, and servers do not receive it.

On export, AetherCut feeds canvas frames into either the WebCodecs VideoEncoder API (Pro tier, supported browsers) or the browser's MediaRecorder (fallback). Both encoders run inside the browser process. The output blob is handed to a <a download> link, which the browser writes to your local Downloads folder.

Our servers see none of this. The only HTTP request that crosses our network during a full edit-and-export workflow is the one that loaded the editor's JavaScript in the first place.

Verify it yourself

• Open DevTools (F12 on most browsers).
• Click the Network tab.
• Drop a video into the editor and make a cut.
• Export.
• Filter the requests by Media or XHR.
• Count the outbound video bytes. The number you are looking for is zero.

If the number isn't zero, email the founder at AethercutAdmin@gmail.com and we will treat it as a P0 bug.

Why local editing can still look like network activity

If you inspect the page while editing, it is normal to see browser activity that has nothing to do with your video leaving the device. Modern browsers may fetch the app bundle, fonts, icons, or cached script chunks, and DevTools can make that look busy even when the media pipeline is fully local. The important distinction is the request type and payload: a blob: URL is not a real upload target, and playback, seeking, thumbnail generation, and export can all happen against that in-memory reference without creating an outbound media request.

A practical way to check is to open DevTools before loading the editor, switch to the Network tab, and preserve the log. Then add your file, scrub through several points, make a few cuts, and export. You may still see the browser reading metadata, decoding frames, or writing the finished download, but those are local browser operations. What you should not see is a POST, PUT, fetch, or XHR carrying your MOV, MP4, or MKV bytes to a remote origin during the edit flow.

One common source of confusion is the final save step. When the browser starts a download, it can feel similar to an upload because a new file appears and the download shelf opens, but that action is the browser writing the exported blob to disk on your machine. Another is memory pressure on very large files: if the browser slows down, that does not mean AetherCut has fallen back to a server. It usually means your device is doing the decode, frame extraction, and encoding work locally, exactly as intended.