Compress video.

Most upload your video to a server, queue it, compress it there, and send it back. That can be perfectly well-meaning — but it does mean someone else's machine briefly held your footage, and you had to trust their retention policy. We sidestep that by not having a server at all. Your file goes from your disk into a Web Worker in this tab, and the compressed MP4 comes back out the other side. There is no /upload endpoint to find — the page's CSP would refuse to talk to one if there was.

There's no hard cap baked into the tool. The practical ceiling is your machine's RAM — multi-gigabyte talking-head clips compress fine on a modern desktop; we've tested well past 2GB. The input file is read with File.stream(), which pulls chunks from disk lazily so we don't load the whole thing into RAM at once. Demuxing happens in mp4box.js; transcoding uses the browser's native WebCodecs (hardware-accelerated where available); muxing uses mp4-muxer. All of it runs inside a Web Worker so the UI stays responsive and the encoder's memory is isolated.

Because we don't need them. Other compressors ask for an email so they can mail you a download link — they need to, because compression is happening on their server and you're waiting in their queue. We don't have a server, there's no queue, the work happens in this tab on your machine, and the download fires the moment it's ready. Same logic for notification permission, sign-up, accounts. The whole transaction starts and ends with you dropping a file.

Today: MP4 / MOV / M4V containers with H.264 (avc1) or HEVC (hvc1) video, AAC audio. The output is always MP4 (H.264 + AAC passthrough). WebM, MKV, AV1 and AC-3 audio are on the roadmap.

If the source audio is AAC (the usual case for MP4), it's passed through unchanged — no quality loss, no extra encoding pass. If the source has a non-AAC audio track, the audio is dropped in this V1 (a warning shows up in the tool). Re-encoding non-AAC audio to AAC is on the roadmap.

Tiny ≈ 1.5 Mbps · Smaller (recommended) ≈ 4 Mbps · High ≈ 7.5 Mbps. The encoder uses variable bitrate, so simple footage (talking heads, screen recordings) lands well under those numbers; busy shots get more bits.

If the source is larger than 1920px on the longest edge, we scale down to 1920 (keeping aspect ratio). Otherwise the resolution is preserved. We don't upscale.

Yes, with caveats. Safari from iOS / iPadOS 17.4 onward has WebCodecs, so the pipeline runs. The real ceiling is RAM: an iPad Pro with 8–16GB should comfortably chew through 1–2GB clips, but a base iPad or iPhone (4–6GB shared memory) will run out of headroom on bigger files. HEVC support also varies a bit between Safari versions. Honest rule of thumb: phones / base iPads for short clips, iPad Pro or a laptop for the multi-gigabyte stuff. The diagnostic panel under the progress bar will show you when it's struggling.

No. The site is a static bundle served from a CDN — there is no backend to receive files. The only outbound network request from this page is the small Cloudflare Web Analytics beacon that records anonymous page views. The CSP header on this site browser-enforces that — any attempt to fetch / upload anywhere else would be blocked.