The Video Resizer tool processes your video entirely inside the current browser tab, so the source file is never uploaded to a remote server when you resize it. Decode, canvas resizing, frame capture, and WebM recording all happen locally using built-in browser APIs, which means the only network traffic is the page itself loading and the resulting WebM file downloading back to your device. Because the source sits in your browser's memory and never crosses a network boundary, there is no server-side queue, no remote transcoding farm, and no temporary upload copy waiting to be deleted elsewhere. The output is a freshly created WebM produced by the browser's MediaRecorder with a finite duration written into the container; the input stays where you put it. This local-only model is fundamentally different from cloud resizers that send your file over the internet, charge per minute, or impose upload caps, and it explains why the resize job takes about as long as the clip itself rather than appearing instantly the way a metadata-only tweak would.
Why a Local Browser Resizer Does Not Upload Your File
The privacy concern behind questions like "is the video uploaded when i resize video" usually comes from past experience with cloud tools that stream large files to a remote server, hold them for several minutes, then email a link back. A local browser resizer reverses that flow. The page loads, you pick a file from your device, and the browser opens that file in memory using its built-in video decoder. From there, every step — drawing each frame onto a resized HTMLCanvasElement, capturing the canvas stream with captureStream, and recording that stream with MediaRecorder — runs on your machine. The Video Resizer on this site is built around exactly that pipeline, so the source file is read, never transmitted.
To confirm this yourself, open your browser's Network panel or DevTools view before you click Resize video. No request carrying video bytes goes out to any third-party host during decoding or recording. The only data movement you should see is the page assets that already loaded when you opened the page and the eventual download of the WebM result you triggered. If a tool you are testing shows large outbound traffic during the resize step, that is the signal it is not actually doing the work locally.
Resize a Video Locally in Three Steps
The simplest way to verify the no-upload claim is to perform the resize and watch what actually happens. Three steps take you from a local MP4, WebM, MOV, M4V, or Ogg file to a downloaded WebM without ever handing the source to a remote server.
- Choose one supported local video using the file picker and wait for the browser metadata to load. The page reads duration and pixel dimensions so it can validate the source against the 500 MiB, five-minute, and 4096-pixel-per-side caps before any re-encoding starts.
- Enter a maximum width and height, then pick Fit to preserve the source aspect ratio inside that bounding box or Stretch to force the exact requested dimensions even if it distorts the picture. Odd numbers are rounded down to the nearest even pixel because browser video encoders are more reliable with codec-safe even sizes.
- Select Resize video and keep the current tab open for the duration of the real-time encoding. The page runs at up to 30 frames per second, attaches any browser-exposed audio tracks, and finishes by exposing a downloadable WebM file made in the same tab.
Each of those steps runs against the local Video Resizer, and if you want a longer walkthrough of the no-upload pipeline, see the guide on resizing without uploading.
Fit vs Stretch and How Geometry Stays Local
Fit and Stretch are different geometry choices, and the choice does not change whether the file is uploaded — both modes run locally on the source you already picked. The table below summarizes what each mode does to your frame inside the browser pipeline.
| Mode | How Your Numbers Are Treated | Output Geometry | Effect on Source Ratio |
|---|---|---|---|
| Fit | Width and height as a maximum bounding box | Smaller-of-the-two scale, never cropped | Preserved exactly |
| Stretch | Width and height as exact pixel targets | Forced width × forced height | Intentionally distorted if the source ratio differs |
Fit mode applies the smaller of the width or height scale so the resized picture sits inside the rectangle you requested without ever cropping the source. Stretch mode uses your numbers directly as the new pixel dimensions, so a 16:9 source going into a 1:1 target will visibly squash horizontally. The tool rounds each final dimension to a positive even integer before drawing, which keeps MediaRecorder VP9 and VP8 configurations stable across the most common desktop and mobile browsers.
What the Browser Does Between Pick and Download
Once you press Resize video, the browser takes over with a fixed pipeline that never asks a server for help. It decodes the source frame-by-frame, draws each frame onto an HTMLCanvasElement sized to your final even-pixel dimensions at up to 30 fps, and uses captureStream to expose that drawing as a live MediaStream. MediaRecorder then wraps the stream in a supported VP9 or VP8 WebM configuration with a bounded bitrate, attaches any audio tracks the browser can read from the source, and writes the container directly to a Blob. After recording stops, the WebM receives a finite duration through the shared audited Matroska duration writer, and a local object URL is exposed for download. If the source uses an unsupported codec, carries invalid dimensions, or produces an empty recorder output, the tool fails visibly instead of handing you a misleading file.
This real-time re-encode is functionally why processing takes roughly as long as the video plays. The work happens at the same speed a viewer would experience; it is not a metadata-only dimension tweak and it is not an upload-and-wait job that would suddenly appear in your downloads minutes later.
Source Limits, Output Differences, and Honest Trade-offs
The local model also defines what the tool cannot promise. The source must be a browser-decodable MP4, WebM, MOV, M4V, or Ogg up to 500 MiB, five minutes long, no more than 4096 pixels per side, and no greater than 3840 × 2160 pixels in area. Each target dimension has to be a whole number from 2 to 1920 pixels. The output is a freshly re-encoded WebM, so quality, bitrate, frame timing, audio layout, color metadata, and file size will not match the source bit-for-bit. The encoder does not upscale detail, remove black bars, crop a subject, preserve subtitles or multiple tracks, bypass DRM, or claim professional mastering. Editing rights also stay your responsibility — the tool reminds you to use only media you own or may edit. For frame-accurate delivery, long-form footage, required MP4 output, color-managed workflows, or exact bitrate control, you still want a dedicated desktop encoder.
Knowing those boundaries up front is the simplest way to avoid a confusing result. The Video Resizer is built for the common case of shrinking a short clip to a target bounding box in your own browser; everything outside that scope is a sign you want a different tool, not a sign that local resizing failed.
For a deeper look, see What Can Go Wrong When You Resize Video (and Fix It).