How to reduce mp4 size for discord with full privacy
- Step 1Load the tool, then go offline to verify — Open the Discord compressor. To prove the privacy claim for yourself, turn off Wi-Fi / disconnect after the page loads — the encode below will still run, because nothing is sent anywhere.
- Step 2Drop the confidential MP4 — Drag the file in or click to browse. It's read into the tab's memory via the File API; it does not begin any network request. The file list shows size, duration, and resolution, all read locally by a hidden
<video>element. - Step 3Keep Target size on 25 —
25targets the free-Discord 24 MB ceiling. There are no other controls to leak preferences through — just the size target. - Step 4Run the compressor locally — Click Run Discord Fit. Encoding uses your device's hardware H.264 encoder (WebCodecs) or FFmpeg.wasm — both run in-tab. Open DevTools → Network if you want to confirm no upload request fires during the encode.
- Step 5Download the MP4 to disk — Save the compressed
.mp4. It's generated in-memory as a blob and downloaded directly; it's never staged on a server. Refreshing the page after this clears the source from memory. - Step 6Send it yourself, when you choose — The only network transmission is your manual upload to Discord. Until then the clip has never left your machine.
Where your clip actually goes
The data path for this tool versus a typical online converter. The difference is the whole point.
| Stage | This tool (local) | Typical online converter |
|---|---|---|
| Reading the file | File API into tab memory | Uploaded to their server |
| Encoding | Your GPU/CPU in the browser | Their server CPU |
| Storage during job | RAM only, in your tab | Their disk, for an unknown window |
| Account / email | None needed for 25 MB target | Often required |
| After you're done | Refresh = gone from memory | Retention policy you must trust |
| Network events | Only your manual Discord send | Upload + download + their analytics |
What the output does and doesn't contain
A local re-encode produces a clean MP4 — no SaaS extras.
| Property | This tool's output |
|---|---|
| Container / codec | MP4, H.264 video + AAC audio |
| Watermark | None |
| Injected SaaS metadata / tracking | None |
| Source metadata | Re-encode produces a fresh stream; original container tags aren't carried over |
| Faststart flag | +faststart set so it plays instantly |
Cookbook
Privacy-sensitive scenarios and how the local-only design handles them. The recurring theme: the clip never leaves until you send it.
A recorded internal call clip
A 2-minute snippet of a screen-shared internal meeting, too big for the cap. Sending it to a random converter would leak the contents; the local encode keeps it on your machine.
Input: standup-clip.mp4 · 140 MB · 120.0s · 1080p Process: read into tab → encode on-device → blob download Network during encode: none (verify in DevTools) Output: discord-fit.mp4 · ~24 MB Result: shared to the team channel, never on a 3rd-party server
Proving it's offline
The strongest privacy test: disconnect the network and watch the encode still finish. This works because FFmpeg.wasm / the WebCodecs encoder are already loaded in the page.
1. Load the tool page (online) 2. Disable Wi-Fi / pull the cable 3. Drop the MP4, target 25, Run 4. Encode completes; download the result Conclusion: no network = it's genuinely local
An NDA-covered product demo
A pre-launch feature capture you can only share in a private channel. No account, no upload, no record of the file anywhere but your disk and the channel you choose.
Input: feature-demo.mov · 300 MB · 4 min Target: 25 → 24MB; video ~710 kbps (UI stays legible) Output: discord-fit.mp4 · ~24 MB Audit trail: only your deliberate post to the private channel
Stripping the SaaS-converter risk entirely
Instead of trusting a converter's retention policy, the clean re-encode produces a fresh MP4 with no injected watermark or tracking — and no copy left behind.
Online converter output: watermark + their metadata + a copy retained on their disk for N days This tool's output: plain H.264 MP4, +faststart, no extras, no retained copy (source clears on page refresh)
Confirming no upload in DevTools
For a paranoid check, open the Network panel before running. You'll see the WASM/core assets load once, then zero file-upload requests during the encode.
DevTools → Network → clear → Run Discord Fit
Expected: ffmpeg-core / WebCodecs assets (cached after 1st run)
NO POST/PUT carrying your video bytes
The video bytes never appear in any requestEdge cases and what actually happens
Source metadata isn't carried into the output
By designBecause the tool re-encodes (not stream-copies), the output MP4 is a fresh stream and the original container's title/creation-date/camera tags don't carry over. That's a privacy bonus here. If you specifically want to scrub metadata from a file without re-compressing, use the metadata scrubber instead.
Pixel content is unchanged — frames aren't redacted
Not a redaction toolCompression doesn't hide anything visible in the frame. If your clip shows a face, name, or screen secret you need to obscure, compress alone won't do it — use the video redactor or face blur first, then compress the redacted result here.
Page refreshed before download
Source clearedAll state lives in the tab. If you refresh or close before downloading, the source and the in-progress output are gone from memory — by design, so nothing lingers. Just re-drop the file and re-run.
Duration can't be probed
ErrorThe bitrate calc needs duration; a clip with no readable duration throws Could not determine video duration. Re-mux locally through the transcoder (also fully local) and retry.
Output slightly over 25 MB on a very long clip
Soft warningPast ~12 minutes the 200 kbps video floor can push output over 24 MB; you still get the file (console warning only). Trim with the lossless trimmer — also local — to get safely under the cap.
Large file on the software path
Error if memory runs outOn the FFmpeg.wasm fallback, a very large source can exhaust the WASM heap (Aborted(OOM)). The tool returns a plain message rather than leaking any partial data anywhere — the failure is local too. Use a hardware-encode browser (Chrome/Edge) or a smaller source.
Free tier file-size limit
1 GB / 1 fileThe Free tier processes up to 1 GB per job, one file at a time — all locally. Higher tiers raise the size and batch counts but don't change the local-only architecture; even paid jobs never upload the video.
Output plays instantly — that's +faststart, not a leak
ExpectedThe MP4 is muxed with +faststart, which moves the index to the front so it streams from the first byte. That's a local muxing flag, not any kind of network behaviour — it just means recipients see the clip play immediately on Discord.
Frequently asked questions
Is my video really not uploaded anywhere?
Correct. The file is read into your browser tab via the File API and encoded there — using your device's hardware H.264 encoder (WebCodecs) or FFmpeg.wasm. No part of the video is sent to any server. You can prove it: disconnect your network after the page loads and the encode still completes, or watch DevTools → Network and confirm no upload request carries the video bytes.
Do I need an account?
No — the 25 MB target works with no account, no email, nothing. There's no profile to associate the clip with. Paid tiers (for larger files and batching) require an account, but even then the video is never uploaded; the account only gates limits.
How is this different from an online video compressor?
An online compressor uploads your clip to its server, encodes it there, stores a copy under some retention policy, and often adds a watermark or tracking. This tool does all the work in your browser, keeps the file in RAM only, leaves no server copy, and injects nothing. The difference is the entire data path.
Does the output keep my original file's metadata?
No. Because it re-encodes rather than copies, the output is a fresh H.264 stream and the original container tags (title, creation date, device model) don't carry over — a privacy plus. If you want to scrub metadata without re-compressing, use the metadata scrubber.
Can compression hide sensitive content in the frame?
No — compression changes bitrate, not what's visible. To obscure a face, name, or on-screen secret, blur or redact first with face blur or the video redactor, then compress the redacted clip here. Don't rely on compression for confidentiality of visible content.
What's the only time my clip touches the network?
When you manually upload it to Discord. The compression, the metadata read, the size verification — all local. The deliberate send is the single, user-controlled network event in the whole flow.
What codec and container does it output?
MP4, H.264 video + AAC audio, with +faststart set for instant playback. No watermark, no injected SaaS metadata, no tracking. A clean, standard file.
Is the encode logged or analytics-tracked with my filename?
The video bytes never leave your device, so they can't be logged server-side. Anonymous usage counters (a tool ran) may be recorded, but never your file contents or video data. Run it offline if you want zero network activity at all during the encode.
What if the file is too long and the output exceeds 25 MB?
Past ~12 minutes the bitrate floor can push the output a little over 24 MB; you still get the file with a console warning. Trim it locally with the lossless trimmer (which copies streams without re-encoding) to get under the cap while keeping everything on your machine.
Can I do this for a confidential clip on a managed/locked-down laptop?
Usually yes — it's just a web page running browser-standard APIs (WebCodecs / WebAssembly), no install, no plugin. As long as the browser allows JavaScript and file access, it works. Nothing needs admin rights or network egress for the encode itself.
How do I prove to my security team it's local?
Two demonstrations: (1) load the page, disable the network, and show the encode still completing; (2) open DevTools → Network during a run and show that no request carries the video payload. Both are reproducible on any machine.
Does it work for clips other than MP4?
Yes — it accepts MP4, MOV, MKV, WebM, AVI, M4V, and TS, all processed locally, and always outputs MP4. The privacy guarantee is the same regardless of input format.
Privacy first
Every JAD Video tool runs entirely in your browser via WebCodecs and FFmpeg (WebAssembly). Your video files never leave your device — verified by zero outbound network requests during processing.