Real answers, no marketing speak

Yes. The compression runs inside the browser tab using WebAssembly. The file you drop in stays in your device's memory and never gets sent over the network. You can confirm by opening DevTools → Network and watching the bytes counter while you compress: it doesn't move.

No, there isn't an upload step. The page itself is small (~250 KB), and the compression engine fetches once on first run, around 26 MB. After that everything happens locally — encode, mux, download — without your video crossing any wire.

We don't have your videos. There's no server we could store them on, no dataset to feed them into. Open-source video AI training datasets pull from public sources, not from random compressor users — but in our case, the architecture makes it physically impossible regardless.

We log success/failure counts, file size in MB, source format, and country (from Cloudflare's edge), all anonymized. We do NOT log file names, content, or anything that ties an event to a specific person. If you don't want to be in those counts, an ad blocker or DNS-level block will skip the telemetry beacons cleanly.

Yes, free. There's no paid plan, no email gate, no "upgrade to remove watermark" upsell. Our running cost is essentially zero because compression happens on your device — Vercel's free tier hosts the page, Cloudflare's free tier handles a tiny analytics endpoint.

Most online compressors run the encode on their server, which means GPU bills they have to recoup. We pushed the encode to your browser instead. Different architecture, different unit economics.

We set the upper bound at 2 GB. The real ceiling is your device's RAM — desktops handle 2 GB cleanly, phones usually start to struggle past 500 MB to 1 GB. The upload card shows what your specific device can comfortably manage.

No. Some hosted tools throttle to 3-5 conversions per day on free tier; we don't, because each compression costs us nothing.

No. The output is identical bytes to what a paid encoder would produce at the same settings. No logo overlay, no audio jingle, no metadata branding.

No account, no email. Drop the video, pick a target size, click compress, download. The whole flow is anonymous.

Pick the WhatsApp preset on the homepage. We target ~15 MB to leave headroom — WhatsApp rejects right at 16 MB on some clients. If your source is much shorter than 1-2 minutes, you can use the Custom slider and aim lower for visibly better quality at the same final size.

Discord preset → 10 MB target. Works for clips up to about 90 seconds at watchable quality. Past that, drop resolution to 720p or below in Advanced Settings.

Same Discord preset, but raise the target to 500 MB. Most full-quality 1080p clips up to 6-10 minutes fit without visible loss.

Email preset targets the lower number (20 MB) so the file works regardless of which provider the recipient uses.

All three preserve original quality at upload, so we target a generous size (200-500 MB depending on platform) and let the platform do its own re-encode. Your input quality matters more than your output size for these.

Some loss is unavoidable when you're shrinking the file 5-10×, but it's almost always invisible to the eye at the targets we pick. We use H.264 with smart bitrate allocation — easy scenes (talking head, slow pan) cost less, action scenes get more bits. The bigger drops happen below 720p or under ~500 kbps.

VBR encoders allocate fewer bits when the source is easy to compress (low motion, static scenes). If you asked for 100 MB and got 45 MB, the output is the SAME visual quality the 100 MB version would have been — just more efficient. We show a confirmation banner when this happens so it doesn't look like a bug.

Your source was probably already compressed efficiently (low bitrate H.264 from a phone, for example). Re-encoding it at a generous target adds bits back. The fix is to either lower the target, or accept the source unchanged — we offer both options on the result screen.

MP4 with H.264 video and AAC audio. It plays everywhere — phones, browsers, smart TVs, Discord, every messaging app. We default to this for that reason. MOV is the same wrapper, useful if you specifically want a QuickTime file.

Safari and Chrome on iOS 16.4 or later. iOS 26.4+ adds hardware video encoding for noticeably faster runs. Practical file size limit on iPhone is around 1 GB before Safari starts releasing memory.

Chrome, Edge, or any Chromium browser on Android 12 or later. Hardware encoding is available on most modern Android devices, so a 100 MB clip typically takes 10-30 seconds.

Chrome, Edge, Brave, Opera, Vivaldi (any recent Chromium): full hardware-accelerated path. Safari 17+: same, slightly slower. Firefox 150+: works but ~10× slower because Firefox hasn't shipped hardware H.264 encoding yet (Mozilla bug 1918769). We auto-detect Firefox and warn before you start.

Mozilla hasn't enabled the hardware H.264 VideoEncoder backend in Firefox's WebCodecs implementation. We fall back to a pure-software encoder, which works but runs at ~10% the speed of Chrome's hardware path. For a 500 MB clip the difference is ~30 minutes vs ~3 minutes. Switch to Chrome or Edge if speed matters.

HandBrake runs natively, so on huge files (multi-GB sources, multi-hour videos) it's still 2-4× faster than any browser. For one-off compressions, normal phone-clip sizes (under 2 GB), and zero-install convenience, this tool is competitive. Different tools, different sweet spots.

Your original file on disk is untouched. We never modify the source — we read it, build a new file, and try to hand you the new file. If something breaks, the result screen tells you why (low memory, unsupported codec, etc.) and the original is still where it was.

Yes. The review screen has a trim tool — drag handles to set start and end. Trimming runs alongside compression so it doesn't add wall-clock time.

Open multiple browser tabs. Each tab runs an independent compression on your CPU/GPU. We don't artificially gate concurrent jobs because each one runs on your own hardware.