· VideoFreeTier

AI Video Upscaler Free: Which Free Upscalers Really Keep the File on Your Machine

Three free AI video upscalers ranking for this phrase say the file is processed in your browser and never uploaded. A packet capture run here on 12 October 2026 put a 137 KB test clip through them. On the two that produced output the clip never left the machine — the largest upload either page made was 34 KB, and the clip's own marker never appeared in any request body. The top-ranked tool read the clip and then stalled at "Reading file".

Model
AI video upscalers, free tiers
Observed

Three of the free AI video upscalers ranking for this phrase say the file is processed in your browser and never uploaded. A packet capture run here on 12 October 2026 put a 136,931-byte test clip through them, and on the two that produced output the clip never left the machine: the largest upload either page made was 34 KB, and the clip's own marker never appeared in any request body. The tool that ranks first read the clip — it reported the resolution back correctly — and then stalled at "Reading file" without finishing, so nothing can be claimed about it either way.

A small desk in low light with a laptop, a printed frame sheet and a folder of notes

Measured on 12 October 2026 on one Windows machine, using the tool pages that Google's US results return for this phrase. This is not a record of what the pages state — it is what left the machine when each page was actually run. One page could not be run to completion and is marked as such rather than filled in.

The claim, and the two instruments that tested it

"Processed locally, never uploaded" is a testable sentence. A browser cannot upscale a video without either doing the arithmetic on the machine or sending the file somewhere that does. So the test is a packet capture: attach a clip that carries a marker inside its own bytes, run the tool, and then ask two independent questions — did any request body contain the marker, and did any host receive bytes on the scale of the file.

Two instruments answered those questions separately. The first reads request bodies through the browser's debugging interface. The second is a counting proxy the browser is pointed at, which measures the bytes going upstream on every connection, including inside encrypted tunnels where the contents cannot be read. The first can identify the file; the second can weigh it.

Before any absence could be written down, both instruments had to prove they could see a known upload. A local page posted the same clip to a local server: the server received 137,131 bytes with the marker inside, the body reader caught the marker, and the proxy counted 137,131 bytes upstream to that host — byte for byte. Without that step a "nothing was uploaded" result would only mean the instrument was blind, which is exactly what an earlier version of this test turned out to be.

What each page claims, and what left the machine

PageGoogle rankIts own wordsWhat the capture found
free.upscaler.video1"Upscale videos or images with AI for free, right in your browser - no signups, installation or config necessary"Clip was read (the page reported 640×360 → 1280×720, which is the test clip), then stalled at "Reading file" 0% for over four minutes. Largest upstream 26,217 bytes. Marker not seen. No conclusion drawn
freeupscaler.app3"Runs in your browser. Your files stay on your device." / "Processed locally, never uploaded" / "Free stays 100% local, always — Pro runs in the cloud"Completed. Result delivered in-page: "Original: 133.7 KB → Result: 997.3 KB". Largest upstream 11,732 bytes. Marker not seen
atlascloud.ai10"Video processed locally in browser — Assets aren't uploaded to OSS or processed by AtlasCloud backend"Ran in-browser frame by frame. Model pulled from a CDN into the browser. Largest upstream 33,599 bytes. Marker not seen

The middle column is the page's own sentence, quoted so the claim being tested is visible. The right column is the measurement, and it is the only column on this page that is not a quotation.

atlascloud: the model comes down, the clip does not go up

The page states that assets are not uploaded and are not processed by the backend. What the capture shows is consistent with that, and the shape of the traffic says why: the browser downloaded 54,538,528 bytes from a model-hosting CDN and 4,394,743 bytes of runtime code, then began reporting its own progress in frames.

The tool read the clip as 3 seconds at 6 output frames per second and counted 18 frames to work through. In the window this test allowed, it reported four of them:

ElapsedWhat the page reported
7 sLoading local model · onnx/model.onnx, 12%
13 sLoading local model · onnx/model.onnx, 100%
470 sEnhancing frame 2/18, 5%
585 sEnhancing frame 3/18, 9%
730 sEnhancing frame 4/18, 14%

Eighteen frames is what a 3-second clip at 6 frames per second comes to, which is how the page's own arithmetic confirms it was working on the clip that was handed to it. The reason it crawls is visible in the page's own compatibility notice elsewhere on the site: without a GPU the model runs on the processor, and frames that would take milliseconds take tens of seconds.

Across the whole run the largest single upstream transfer to any host was 33,599 bytes, against a clip of 136,931 bytes, and the marker never appeared in a request body. The download direction is where the volume is, and it points at model weights, not at the file.

freeupscaler.app: the result arrives as a blob, not a round trip

This page makes the strongest version of the claim — "Processed locally, never uploaded" — and it also names the boundary itself: free stays local, Pro runs in the cloud. The run completed, and the result panel reported the input and output sizes side by side: 133.7 KB in, 997.3 KB out. The input figure is the test clip to the kilobyte, so the page had genuinely read the file rather than a cached sample. The output arrived as an in-page blob with no server address attached to it.

Upstream traffic for the entire session peaked at 11,732 bytes, and that peak was Chrome's own update check, not the page. The page's own largest outbound transfers were an analytics endpoint and an error-reporting endpoint, both around 10 KB, which is what those endpoints cost on any page and is three orders of magnitude away from the clip.

One qualification belongs here rather than in a footnote. The page ran in what it calls compatibility mode, and it said so on screen: the browser on this machine does not expose WebGPU, so the page fell back to standard browser scaling and reserved its AI mode for browsers that do. So what was verified is that the fallback path uploads nothing. The AI path was not exercised on this machine, and this page makes no claim about it.

free.upscaler.video: the clip was read, and then nothing happened

The top result could not be completed here, and the reason is worth stating precisely because it is easy to write a misleading sentence about it. The page opens its file picker through a browser interface that has no visible file input, so the clip had to be handed to it by substituting the picker itself. That substitution worked — the page read the clip and reported the resolution back as 640×360 going to 1280×720, which is the test clip and not a sample.

Then it stopped. After the upscale button was pressed the page reported "Reading file" at 0 per cent and stayed there for more than four minutes, with no further movement. Upstream traffic peaked at 26,217 bytes, the marker never appeared, and the page's own host served less than a megabyte in total — no sign of a model being fetched into the browser the way the other two do.

None of that adds up to a finding. A tool that never started its work has not been shown to upload, and it has not been shown to keep anything local either. The likeliest reason it stalled is the same missing browser feature that forced the other page into a fallback, but that is an inference from two observations, not a measurement, and it is labelled as an inference here rather than reported as a result.

What a packet capture can and cannot prove

It can prove that on a given day, on a given machine, a given page did not send a particular file anywhere. That is a real and checkable thing, and it is more than a page's own marketing sentence gives you. It cannot prove the opposite direction in general: a page that uploads nothing in one configuration may upload in another, and a page that stalls proves nothing at all.

The clip itself is the strongest part of the method. A marker hidden inside a file's own bytes travels with the file, so finding it in a request body is proof the file went out, and not finding it anywhere is proof it did not — provided the instrument has already been shown to catch a known upload. The byte counts add the second dimension: a page can avoid sending the file as one request and still send it in pieces, which is why the proxy weighs the whole session rather than looking for a single large body.

Where a page's own compatibility notice changes which code path runs, the measurement only covers the path that ran. This machine has no WebGPU, which is why one page announced a fallback and the other likely stalled. On a machine with a GPU the AI paths would be the ones exercised, and the answers could differ.

The site's own ledger of AI video free tiers — each figure carrying the channel it was seen on, the date it was observed and whether it came from a vendor statement, a report or a single observation — is published as CSV, JSON and Markdown on the data page.

Where the parts of this that can be checked are kept

The clip, the capture output and the page-by-page notes behind this article are dated and stored together, so the numbers above can be traced back to the run that produced them rather than to a summary of it. Nothing on this page is an average, an estimate or a projection.

The two tools that finished are the two that can be described. The one that stalled is named and left at that. A page that reports only the results it liked would be worth less than this one, which is why the third result is here.