Drop a video on the home page — a clip of any length — pick a size (1080p, 2K or 4K) and a quality (Fast, Pro or Ultra), press Start, compare before and after on the same frame, download. Everything runs on your own computer's or phone's graphics chip through WebGPU, and the page measures your device before each run, so the time estimate is yours, not an average.
1. How to use it
- Choose a clip.
MP4, MOV, M4V, MKV, WebM or 3GP, up to 2 GB, any length; AVI, MPG, VOB, WMV, FLV, DV, a camcorder's MTS and the other old formats open too — the page turns them into an MP4 first. The browser reads the clip's resolution, frame rate and length on your device and opens the workbench in place of the drop box. A file this browser cannot open or decode is named the moment you choose it, with the way on: the browsers that open it as it is, or a conversion to MP4 (H.264). If a run later finds the file can no longer be read, the panel asks for it again: with Replace, or on an Android phone — whose gallery can stop letting the browser read a video — from Files.

Drop a clip on the box or press Choose video. - Pick a size and a quality, preview, start.
A platform button (YouTube, TikTok · Shorts · Reels, Instagram, X) fills in the shape, size, file type and frame rate that platform wants. "Preview this frame" runs a short test on the frame you paused on and shows it before and after, with the time estimate; under Start the panel names the setting it recommends for this clip, and its time, one tap away. Then press Start; you can pause and resume, a long run saves its progress as it goes, and a long job offers a 30-second trial first.

Pro on a blocky 480p download: the preview at the top of the panel shows the marked window before and after; Start, its estimate and the recommendation for this clip sit right under it. - Compare and download.
The original sits on the left and the result on the right — same frame, same moment — with a magnifier that shows the same window of both at the result's pixels. Download as MP4, MOV, MKV or WebM with the sound, copied or re-encoded for the format — where this browser cannot carry it into the format you chose, the panel says so before you start. The file size (the video bitrate) is a setting: Smaller, Standard or Larger — about 17.1 / 34.2 / 54.7 Mbit/s for 4K H.264 — or a rate you type (1–100 Mbit/s), and the panel shows the megabytes before you start. Once a run is done, "Export again" rewrites the file in another size, format, container or frame rate from the frames you already have — no second upscale. The result stays in this browser for 24 hours: within that time, "View" under "Choose video" on the home page opens it here again, to play, compare and download. Open the tool when you are ready.

Done: original left, result right, the axis between them draggable.
Screenshots: Komekami! Girl's PV (2026), official channel — CC BY 4.0 via Wikimedia Commons, re-encoded at 220 kbit/s.
Any length — long videos welcome, saved as it goes
- Any length
no cap on the clip — a two-hour film runs the way a ten-second one does, from a file of up to 2 GB
- 15 s
of graphics work before the first finished piece is on disk, then one every 30 s
- 24 h
an unfinished run waits for you — the home page offers to continue it from the last saved piece, frame for frame
The result streams into your browser's private storage while the run goes on, in finished pieces — which is what lets a long video, a full movie or an hour-long recording, run through. A job the estimate puts past 90 seconds gets its first piece after 15 seconds of graphics work, and one more every 30 seconds after that; once that first piece is saved, the panel says the run can be continued after a reload. Close the tab, lock the phone, come back within 24 hours: the home page lists the job, picks it up from the last saved piece frame for frame, and joins the pieces into one file at the end. Shorter jobs run straight through in one piece. You can take the whole clip, a window of 5 seconds to 10 minutes dragged on the filmstrip, or one that ends where you type; the estimate next to Start gives the time on your own device, a long job's panel says how much room it needs and offers a 30-second trial first, and where the browser measures its free space, the page checks the result fits before any graphics work starts.
Old formats: AVI, MPG, VOB, WMV, FLV and camcorder files
Camcorder files open as they are. The MTS / M2TS of an AVCHD camera and TS recordings are rewrapped as MP4 inside the page before the workbench shows them — the pictures copied, not re-encoded, and a Dolby Digital (AC-3) sound track turned into AAC (Opus in Firefox) so every browser plays it; a bar in the drop box shows how far it is, and nothing is uploaded. Most camcorder and TV footage is interlaced, and the panel says so: it is upscaled with its fields as they are, so moving edges can show fine comb lines. Try a short window first, or deinterlace it in HandBrake (step 3 below) for the cleanest result.
DVD rips and older downloads come in containers and codecs that browsers do not read — AVI (often DivX or Xvid), MPG and VOB (MPEG-2), WMV, FLV and DV, and the Motion JPEG of old cameras' AVI and MOV files or the MPEG-4 and H.263 of old phones' 3GP. The page converts such a file into an MP4 inside your browser with FFmpeg's own decoders, fetched the first time you choose one, deinterlacing interlaced pictures on the way, and nothing is uploaded: the beginning opens within seconds — enough to preview it and try a short run — while the rest is prepared behind the workbench, and a run of the whole video starts once it is ready; an AVI or FLV that holds H.264 has its video copied into the MP4 untouched. In a browser without WebAssembly these formats still need a conversion first, and the page says so the moment you choose one. Convert such a file once to MP4 (H.264) at its own size, then upscale the MP4:
- Open the file in HandBrake — free and open source, for Windows, macOS and Linux (for a DVD, open its VIDEO_TS folder).
- Keep the preset it opens with, Fast 1080p30: it writes an H.264 MP4 and keeps a video smaller than 1080p at its own size. For footage at 50 or 60 frames per second, set Video → Framerate to Same as source.
- For a DVD, a tape or a camcorder recording, check that Filters → Deinterlace is on: interlaced video shows combed stripes on anything that moves, and an upscale would sharpen them.
- Start the encode, then choose the MP4 on the home page.
A file that plays in one browser and not in another — an iPhone's HEVC in Firefox — needs no conversion: the page names the browsers that open it as it is. An MKV opens in Safari too, rewrapped the same way.
Which settings for which video
Starting points from our own test footage; the preview decides for your clip. Every row opens the tool with those settings.
| Your video | Try | Why |
|---|---|---|
| Phone or camera footage, 720p–1080p, clean | Fast → 2K or 4K · open with these settings | Fast crispens edges and leaves the look alone; the repair tiers spend minutes per minute of clip to change little. |
| Blurry, shaky or dim phone clip, any size | Fast → 1080p or 2K · open | Blur and shake are not fixed by any tier. Pro only if flat areas (sky, walls, skin) show small squares, like a bad livestream. |
| Anime, motion comics, line art, UI, screen recordings | Fast → the largest size offered · open | Line content gains the most from Fast: crisper edges, no bright rims, nothing invented. A 640 × 480 episode reaches 2K, not 4K. |
| Downloaded anime with blocks, white rims or noise | Pro → 2K (on a phone too: 480p episodes) · open | Pro gives the cleanest lines on animation. A DVD's VOB or MPG is deinterlaced as the page converts it; an interlaced MP4 or MKV rip is cleanest deinterlaced first (HandBrake's deinterlace filter, or ffmpeg's yadif). |
| AI-generated video | Fast → 4K; Pro when it looks smeared and is ≤ 720p · open | Generated clips are clean but soft. Never Ultra on them: it hardens the soft look into wax. |
| Downloaded or re-compressed 480p–720p live footage with visible blocks | Pro → 1080p or 2K · open | Pro removes blocks and light noise most cleanly; on this footage Fast looks the same as a plain enlargement. |
| Old film, heavy grain, the worst 360p–480p sources | Ultra → 1080p or 2K, on a computer; preview first · open | Ultra is the one tier that wins on heavy grain and on footage Pro leaves blocky. A clip that is smeared flat rather than blocky cannot be brought back by any tier — Ultra makes it worse. |
| 1080p with compression blocks | Fast → 4K · open | The repair tiers take sources up to 720p; nothing here repairs a 1080p clip. |
| Faces close up | Fast; for Pro or Ultra, check the skin in the preview — with Ultra, set Denoise to Light · open Ultra · Light | Fast does not restore skin and does not make it plastic; a 4× repair can over-smooth it, and Light denoise keeps more of the skin's own texture. |
| Night and dark scenes | Fast; with visible noise, Pro · open Pro | Fast leaves noise as it is; Pro cleans light noise best; Ultra hardens fine detail. The stripes in a dark sky (banding) stay at every tier. |
| Old tapes with stripes on moving things (interlaced) | An AVI, MPG, VOB, WMV, FLV or DV: choose it as it is. An MP4, MKV or MTS: deinterlace first (HandBrake or ffmpeg yadif), then upscale | The page deinterlaces the old formats as it converts them. The upscale keeps an MP4's or a camcorder file's fields as they are, and would sharpen the stripes. |
| Already 4K | Nothing to do | The page says so and offers no size. |
How long it takes
Time is frames × time per frame: one minute of clip at 30 fps is 1,800 frames. The estimate next to Start is measured on your own device — the settings the clip opens with, every other setting converted from that measurement by the work it takes — and is the one to trust. Under it the panel recommends a setting for the clip: Pro at the largest size it runs, when that finishes within 8× the clip's length — or within 5 minutes for a short clip — and Fast otherwise; Ultra is never the recommendation, and a phone's is Fast. A setting past 5 minutes names a quicker one that saves at least 30 % of the time, and the recommended one, each one tap away. For scale, on an Apple M4 laptop:
| Job | Graphics chip, per frame | Run, per minute of clip |
|---|---|---|
| Fast, 1080p → 4K | 21.1 ms | ≈ 51 s |
| Fast, 720p → 4K (two 2× steps) | 50.7 ms | ≈ 2 min |
| Pro, 720p → 4K | 404 ms | ≈ 16 min |
| Ultra, 720p → 4K | 777 ms | ≈ 31 min |
A flagship Android phone (Adreno 750) takes about 5× as long on Fast — about 4.5 min per minute of 1080p clip to 4K — and slows further as it warms up; a mid-range phone a few times more. A gaming PC with a recent NVIDIA or AMD card should be in the laptop's range or quicker; a laptop with built-in graphics sits between the two.
Asking an AI about your settings

The icons after "Can it run?" open ChatGPT, Gemini or Claude with your device, clip, settings and estimate already typed in (the Copy icon puts the same text on the clipboard for any other assistant); the text links this guide, so the answer comes from the long version, not a guess.
Links that carry settings
A link to this site can name the settings to start from — https://4kvideoupscaler.com/?quality=pro&size=2k opens the page with Pro and 2K ready (the rows above and an assistant's answer link this way); what the device cannot run falls back to what it can, and a link never starts a run.
| Parameter | Values | Meaning |
|---|---|---|
quality | fast / pro / ultra | The quality tier. |
size | 1080p / 2k / 4k | The output size (longer side). |
template | youtube / shorts / instagram / x | A platform template: its shape, size and format, as the panel's own buttons set them. |
steady | on / off | The Steady filter. |
denoise | 1 / 0.5 / 0 | Ultra's denoise strength (Strong / Medium / Light). |
fps | 60 / 30 / 24 | The output frame rate, only below the clip's own. |
reason | blocky / noisy / soft / fast / platform / archive | The main problem the settings answer — a label for our statistics, not a setting. |
via | — | Where the link came from (an assistant, the guide, a share). |
note | up to 60 characters | One line shown with the settings. |
2. Quality tiers
Three tiers, two kinds of network. Fast is a small 2× network that crispens edges. Pro and Ultra are 4× repair networks that rebuild the picture and remove compression blocks and noise: Pro is the cleaner choice for almost everything, Ultra the heavier one for old film and heavy grain. Tier names stay; the network behind a tier may be updated.
Fast
Makes edges crisper, changes nothing else · the tier every device starts on
Doubles the size and firms up edges and lines on top of a plain enlargement. It adds crispness, not picture information: the look, colour and grain are left alone.
- Comparable to
- An Anime4K-class 2× network (a few thousand to about a hundred thousand parameters).
- Per frame
- ≈ 21.1 ms per 1080p → 4K frame; ≈ 50.7 ms per 720p → 4K frame (two steps)
- Best for
- Clean footage, anime, line art, screen recordings, AI-generated video — and everything on a phone.
- Not for
- Compression blocks, noise, old tapes: there it looks the same as a plain enlargement.
- Phones
- Yes.
Pro
Repairs blocky, noisy footage · the cleanest lines on anime · half of Ultra's time
Rebuilds the frame at four times its size while removing compression blocks and light noise — the cleanest de-blocking of the three, and the cleanest lines on downloaded anime.
- Comparable to
- A Real-ESRGAN-class compact 4× network, the lighter member of that family.
- Per frame
- ≈ 0.4 s per 720p frame — about 8× the time of Fast on the same job
- Best for
- Downloaded or compressed anime; blocky or lightly noisy live footage up to 720p.
- Not for
- Sources over 1280 px on the longer side; clean footage, where it costs minutes for little change.
- Phones
- Yes, up to 854 px on the longer side (480p) — one to two seconds a frame, so a short window. At 720p, even a flagship phone works about 27 minutes on a 30-second clip.
Ultra
The heaviest repair · for old film and heavy grain · can smooth skin
The deepest repair: removes heavy grain and noise and sharpens smeared texture. Its denoise strength has three steps under "More options" — Strong, Medium, Light — and Light keeps grain and skin texture. About twice the time of Pro.
- Comparable to
- A Real-ESRGAN-class compact 4× network, the deeper member of that family.
- Per frame
- ≈ 0.8 s per 720p frame — about 15× the time of Fast on the same job
- Best for
- Old film, heavy grain, the worst 360p–480p footage when Pro leaves blocks behind. Preview faces first, and try Light denoise on them.
- Not for
- Clean or AI-generated clips (it hardens them), sources over 1280 px on the longer side, phones.
- Phones
- On computers. Even a flagship phone would work about 50 minutes on a 30-second 720p clip, and a run that heavy can make the browser switch the graphics chip off, so phones are not offered it.
The repair tiers on a phone. Pro and Ultra are 4× restoration networks, and every frame is a long stretch of work for the graphics chip. On a phone that adds up: even on a flagship, a 30-second 720p clip keeps the graphics chip working for about 27 minutes with Pro and 50 with Ultra, and runs that heavy can make the browser switch the graphics chip off. That is why a phone gets Pro on clips up to 480p and Ultra runs on computers; Fast is unaffected.
No tier interpolates frames (frames are only dropped), deinterlaces (the page does that to the old formats as it converts them, before any tier runs), restores faces or changes colour and exposure; each frame is processed on its own, and the optional "Steady" filter under More options only settles grain that flickers in still areas.
3. Before and after
Three real runs of this page's own engine, one per tier, from low-resolution sources: the same window of the same seconds, the source on the left the way a player shows it, the result on the right. Drag the axis.
4. The engine: SR Engine
Every tier runs on SR Engine, our own WebGPU inference engine. There is no general-purpose machine-learning runtime to download: a tier fetches its model file (3 KB to 2.4 MB) the first time it runs, and every compute kernel was written for this family of networks. On the same machine and the same network it is 3.0× faster than the open-source engine we ran before, and it runs the heaviest step in 546 MB of graphics memory — or inside a 128 MiB budget, in 4 bands — where that engine needed about 1.36 GB.
- 3.0×
faster than the open-source engine we ran before — same network, same machine: 21.1 ms against 63.3 ms per 1080p → 4K frame
- 546 MB
of graphics memory for the 720p → 4K second step, or a 128 MiB budget in 4 bands; about 1.36 GB before
- 3 KB
the smallest model file, 2.4 MB the largest — fetched once per tier, no machine-learning runtime to download
Arena memory
112 Bper pixel for the large 2× network — 368 B before
One pool for every intermediate result
All the intermediate results of a frame live in one GPU buffer, sliced by how long each layer's output must survive; a slice is reused the moment its last reader is done. The pass that used to take about 1.36 GB takes 546 MB whole, and fits a 128 MiB budget in 4 bands.
720p → 4K, second step (2560 × 1440 in): 112 B × 3.686 MP is the 413 MB of feature maps, and the 546 MB whole-frame figure adds the weights, the input texture, the output pixels and one readback. Megabytes here are 10⁶ bytes; the compatibility budget is a binary 128 MiB, because that is what the limit it comes from means.
Row bands
4.6%extra rows on the heaviest repair network — 20% before the planner derived each layer's rows from its readers
Big frames in bands, identical output
When a frame will not fit the memory budget, the engine cuts it into horizontal bands, each carrying the rows of context its own layers need, and the output is the same as a whole-frame run down to the last bit. Carrying that context is the only cost, and the planner works every layer's rows backwards from what reads them instead of assuming the worst: 4.6% extra rows on the heaviest repair network, 1.1% on the Fast second pass. Rows the planner stopped recomputing are wall clock on a phone: Fast runs 3.23× faster there with the medium network and 2.02× with the large one, and the heaviest tier fits in 3 bands instead of 4. A device with a 128 MiB binding limit still delivers 4K, and 96 MiB is all a phone is given.
The same second step in 4 bands under the compatibility-mode budget: 42.2 ms per frame, output equal to the whole-frame run. The phone figures are one session on a Xiaomi 14 (Adreno 750).
Half precision
3.5×faster with shader-f16 than the 32-bit path
Half precision, same picture
Where the graphics chip offers 16-bit shader arithmetic, the whole network runs in it: the heaviest repair pass takes 0.78 s per 720p frame, against about 2.7 s on the 32-bit path. Against the PyTorch reference the result stays within 54–70 dB — far beyond what a display can show.
Tests fail below 50 dB (f16) and 60 dB (f32); measured 93–100 dB in f32.
Frame-sized submits
88 msto answer a tap on a phone while a repair job runs — 1024 ms when each frame went to the graphics chip in one go
The page answers while the chip works
A phone's browser paints the page on the same graphics chip the networks run on, and only once the work already handed to it is done: a frame given in one go holds the page for as long as the frame takes. So the engine hands a frame over in pieces of about 12 ms of GPU time — one display frame, measured on the device as it runs — cutting a longer layer into blocks of rows that compute the same pixels, and the page paints between two pieces. On a computer the pieces are 50 ms and the next one already waits in the queue, so the chip never idles: the large 2× network still runs a 1080p → 4K frame in 21.1 ms, against 63.3 ms on the open-source engine we ran before, which submitted once per layer. Between bursts of frames the page also pauses, so a whole run takes about 1.4× the network time and the device stays usable.
A Xiaomi 14 (Adreno 750) running Pro on a 480p clip: the longest the page went without painting fell from 750 ms to 33 ms, for 4% more time per frame — the page painting again takes its turns on the chip.
Pixel-exact
100%of the pixels computed, and the result's mean colour within 1.5 of 255 of the source's
Every pixel computed, the colour unchanged
The engine we ran before dispatched work in blocks of eight, which left the last few columns and rows of a frame unprocessed. It also sampled the frame edge with a repeating wrap, which mixed a quarter of the opposite edge's colour into the outermost ring. Here the edges are zero-padded and every output pixel is the network's own, frames arrive through the 2D path instead of straight into WebGPU — that direct import lifts the mid-tones by 4–8 out of 255 — and an automated export test compares the result's mean colour with the source's. The exported file is written in BT.709, the colour standard players assume for HD video, and tagged as such: the export tests decode colour bars from it to check both.
Both defects were found in the open-source engine we ran before, in its shader dispatch and its display sampler. The lift reproduces in Chrome with an identity pass and no network, in 5 of 7 test clips.
On the device itself
102checks on a Xiaomi 14 (Adreno 750), re-run on every real-device pass
Verified on real phones
A desktop is not evidence about a phone, so the networks run on one: every stored layer is read back on the device and compared with the CPU reference, layer by layer, alongside the operator probes and the 8-bit path. That is how the 3 compiler defects only phone graphics chips showed were caught — 2 on this phone, 1 on a low-end Redmi 14R 5G (Adreno 613) — and each is registered as a workaround that can be switched off, with a probe that re-asks on every run whether it is still needed, instead of the defect being rediscovered the day it stops holding.
The same graphs passed on all 3 desktop engines — Metal, the software renderer and WebKit — and only phones showed these 3.
Eight bits, on phones
3.22 sper 720p frame for the heaviest network on a 2023 phone — 6.24 s on the same phone in 16-bit float
The repair networks, in 8 bits
Where a phone's graphics chip can multiply 8-bit integers four at a time, the engine quantises a repair network's weights to 8 bits and keeps the sums in 32-bit integers, with a calibration file beside the model deciding each layer's scale. Phones run Pro this way; Ultra stays on computers: even in 8 bits, a 30-second 720p clip would keep a flagship phone's graphics chip working for about 50 minutes. Desktops stay on 16-bit floats, where the integer path is emulated and slower.
Measured on a Xiaomi 14 (Adreno 750) in three steps: 7.05 s in 16-bit float on the build this engine replaced, 6.24 s in the same precision here (the planner, 4 bands down to 3), then 3.22 s in 8 bits — 1.94× for the 8-bit step, 2.19× end to end. Correctness is checked on that class of device: 49.9–50.1 dB against the integer reference, where the test fails below 44, and a banded run matches a whole-frame one.
Separable resize
1.8–2.9×faster resize than the pass it replaced, same frames
Two passes beat one
The step that fits a network's output onto the size you asked for used to sample a square of pixels for every output pixel. It now runs as two one-dimensional passes — across, then down — with the horizontal result held in workgroup memory, so the work grows with the width of the filter instead of its square. The filter weights are computed once into a table the shader reads.
Against the CPU reference the resize now lands at 98–102 dB, where the previous one sat at 76–78.
Tuned on your GPU
18%faster on an Apple GPU once the engine picks the block shape
It measures the chip instead of guessing
The fastest block shape depends on the network and the chip together, so the first time a model, a precision and a device meet, the engine runs each candidate on a reduced frame and keeps the fastest; every later run takes the cached answer. A candidate has to win by more than 8% to displace the default. Where the wider block is known to lose — an Adreno 750 runs the repair network 2.5× slower with it, on register spills — nothing is measured at all.
Skipping the measurement on those chips takes first-run setup on the large 2× network from 1.7 s to 1.1 s, and saves 4.7 s on the repair network.
Compatibility first
16 KBof workgroup memory is all the baseline kernel asks for — the floor compatibility mode guarantees
Built to fit old phones' limits
The baseline kernel fits WebGPU's compatibility-mode limits — 4 storage buffers, 128 threads per workgroup, 16 KB of workgroup memory, no f16 — and every kernel is validated against Chrome's compatibility adapter at those default limits, which is the adapter an Android device on OpenGL ES 3.1 is given. Where a device offers more, the engine detects it and steps up.
Zero validation errors at those limits — the default ceilings of WebGPU compatibility mode, which every kernel is shaped to fit.
Reference-checked
227GPU parity cases on each of 3 browser engines
Checked against a CPU reference
A plain TypeScript implementation of the networks defines what "correct" means, and PyTorch outputs of every shipped model are the fixtures. The GPU suite runs those on Chrome (Metal), on Chrome's software renderer and on the Safari engine, plus odd sizes, bands, device loss and misuse. The 618 shader texts the engine generates are pinned as well, so a kernel that changes has to say so.
A per-frame time more than 10% over the recorded baseline fails the build.
Model container
3 KBto 2.4 MB per model, fetched when a tier first runs
A new model is a file
Models ship in a self-describing container: the network graph in a header, the weights as 16-bit tensors. The engine plans memory, kernels and bands from the header, so adding or swapping a tier is a converted weight file, and the container can blend two weight sets at load time.
The container covers the whole family: 3×3 and 1×1 convolutions, ReLU / LeakyReLU / PReLU / CReLU, dense concatenation, pixel shuffle.
Against the engine we ran before
| Property | SR Engine | The open-source engine we ran before |
|---|---|---|
| Memory per pixel, large 2× network | 112 B | 368 B |
| 720p → 4K second step, graphics memory | 546 MBor 128 MiB in 4 bands | ≈ 1.36 GB |
| 1080p → 4K, large 2× network | 21.1 ms / frame | 63.3 ms / frame |
| 1080p → 4K, small 2× network | 3.1 ms / frame | 8.4 ms / frame |
| 8-bit integer path on phones | Yes — where the chip has an integer dot product | No |
| 4× repair networks | Yes | No — 2× only |
| Precision | f16 where offered, f32 otherwise | f32 only |
| Frame edges | Every pixel computed | Last columns skipped, edge colour wrapped |
| How a frame is handed to the GPU | In slices of GPU timeabout 12 ms each on a phone, 50 ms on a computer, measured as it runs | One submission per layer |
| Android compatibility mode (OpenGL ES 3.1) | Fits its limits | No |
| First-run setup, large 2× network | 1.1–1.7 sonce per device: the block shape is measured on your GPU and kept | Fixed block shape |
| Model files | 3 KB to 2.4 MB per tier | The same networks, as JSON weights |
Both engines measured by us on Apple M4 (10-core GPU), Chrome on Metal, same networks. General-purpose machine-learning runtimes in the browser are not in the table: they need a 10–20 MB WebAssembly download before the first frame.
FAQ
- Which quality should I pick?
- Fast for clean footage, anime, screen recordings, AI-generated video and most clips on a phone: it crispens edges and changes nothing else. Pro for downloaded, re-compressed or lightly noisy sources up to 720p: it removes the blocks and the noise. Ultra only for heavy grain and old film. Under Start the panel recommends a setting for your clip: Pro when it finishes within 8× the clip's length on your device, otherwise Fast — never Ultra, and Fast on a phone. When unsure, press "Preview this frame" and compare.
- How long does upscaling take?
- Frames × time per frame; the page measures your own device before it starts and shows the estimate next to Start. On an Apple M4 laptop, one minute of clip at 30 fps takes about 51 s from 1080p to 4K with Fast, about 16 min with Pro from 720p and about 31 min with Ultra; a phone is several times slower. There is no length limit: a long run saves its progress and the home page offers to continue it after a reload. To do only a part, drag a window of 5 seconds to 10 minutes on the filmstrip, or type where it ends; a long job offers a 30-second trial first.
- Why is 4K not offered for my clip?
- The biggest size offered is 4× the clip's longer side: 4K needs a source of at least 960 px on that side, 2K at least 640 px, 1080p at least 480 px; a clip under 480 px is offered nothing, and a clip that is already 4K has nothing to gain. A phone is offered the same sizes as a computer.
- Why is Ultra (or Pro) greyed out for me?
- Pro and Ultra need hardware rendering with half-precision shaders (shader-f16) and a source no wider than 1280 px on the longer side. On a phone, Pro takes clips up to 854 px (480p) and Ultra runs on computers: even on a flagship phone, a 30-second 720p clip keeps the graphics chip working for about 27 minutes with Pro and 50 with Ultra, and runs that heavy can make the browser switch the graphics chip off. Tapping a grey button shows the reason for your device. In Firefox on a computer the reason is usually the browser, not the device: without half-precision shaders it runs Fast, and Chrome or Edge on the same computer run Pro and Ultra.
- Which browsers and devices work?
- Chrome and Edge 113 or newer on Windows, macOS and ChromeOS; Chrome 121 or newer on Android 12 or newer; Safari 26 on macOS, iOS and iPadOS; Firefox 141 or newer on Windows and 145 or newer on Apple Silicon Macs. Browsers inside apps — TikTok, WeChat, Instagram, phone-maker browsers — usually have no WebGPU; open the same link in Chrome or Safari. Where an app's own browser does run it, an iPhone saves the result through the share sheet ("Save Video" puts it in Photos), and on Android the page asks you first to open the link in Chrome, which saves to Downloads. If Chrome or Edge switch WebGPU off after the graphics chip stops responding, the panel says whether it comes back by itself or after a browser restart, and Start turns back on when it does.
- What happens to an AVI, VOB or camcorder file?
- The page makes an MP4 of it first, inside your browser. AVI, MPG, VOB, WMV, FLV and DV — and the Motion JPEG of old cameras or the MPEG-4 and H.263 of old phones — are converted with FFmpeg's own decoders and deinterlaced on the way: the beginning opens within seconds while the rest is prepared, and an AVI or FLV that already holds H.264 has its pictures copied untouched. A camcorder's MTS, M2TS or TS is rewrapped with its pictures untouched. Nothing is uploaded; "Old formats" above has the details.
- Is the sound kept?
- Yes, wherever the format you download can carry it: the sound is copied as it is, or re-encoded where the format needs its own codec (Opus for WebM). Where this browser can carry it into neither, the panel says so before you start and names the formats that keep it. A camcorder's Dolby Digital (AC-3) sound becomes AAC (Opus in Firefox) when the file opens, so every browser plays it.
- What happens if I close the page or lock my phone?
- A run the estimate puts past 90 seconds saves finished pieces as it goes: close the tab and, within 24 hours, the home page offers to continue it from the last saved piece. While a job runs the page keeps the screen awake. On Android, switching to another app pauses the job, and it goes on when you come back to the page; on an iPhone or iPad, locking the screen or switching apps stops it, and the page continues it from its last save by itself once you are back — up to 3 times in a row.
- Does it deinterlace?
- The old formats, yes: AVI, MPG, VOB, WMV, FLV and DV files are deinterlaced as the page converts them. The upscale itself keeps the fields as they are, so an interlaced MP4, MKV or camcorder file (MTS) is upscaled with them — the panel says so, and moving edges can show fine comb lines. For the cleanest result, deinterlace such a file first in HandBrake (Filters → Deinterlace), or try a short window to see how much it shows.
- My file is over 2 GB — what can I do?
- 2 GB is the most one file can be here. Split it into parts with the free LosslessCut — no re-encoding, no quality lost — or export a smaller file with the free HandBrake, then upscale the parts one at a time. Length is never the limit, only the size of one file.
- Where is my upscaled video?
- In this browser's private storage for the site until you download it: the Download button in the finished view saves it wherever your downloads go. It stays there for 24 hours, as the finished view says — come back to the home page within that time: "View" under "Choose video" reopens it to play, compare with the original and download again, and × deletes it. While a result is not downloaded or a job is running, leaving the workbench — its close button, the logo, another video, the back gesture — asks first.
- How do I get the cloud version?
- It is invitation-only. Fill in the form at the end of this page (or email the cloud address with the subject "Cloud access"): what you tried locally and what was missing, the footage, your device. Requesting is free. A cloud version needs an account and, for some models, a fee — the invitation says what applies.
5. Cloud version
The cloud version is for what your own device cannot do in reasonable time: a whole episode with Pro or Ultra on an ordinary laptop, a batch of files, a device without WebGPU, a phone whose graphics chip is not offered the repair tiers. Access is by invitation — tell us what you tried and what was missing, and we invite first the requests it can already serve. Requesting is free; the cloud version needs an account and, for some models, a fee, and the invitation says what applies before you send any footage.
Your address is used to contact you about cloud access and for nothing else (privacy policy).