The most common reason to compress a video isn't storage. It's a hard cap on the other end of the share. WhatsApp drops the file if it's over 16 MB. Discord's free tier rejects anything over 25 MB. Gmail attaches up to 25 MB before forcing you into a Google Drive link. Slack workspaces vary by plan. Twitter, ironically, will compress your video for you but in a way that often looks worse than if you'd done it yourself.

The good news is that for almost every "my video is too big" problem, the file is much bigger than it needs to be. A 4K screen recording with 60fps and 50 megabit bitrate produces a huge file even when the content is mostly a static text editor. Re-encoding the same footage at 1080p, 30fps, and a sensible CRF often shrinks it 10–20x with no visible quality loss. The trick is knowing which knobs to turn and which to leave alone.

TL;DR

  • Use Clipy's video compressor. Drop the file in, pick a target size or quality preset, download the smaller MP4. Runs in your browser — no upload, no account.
  • For WhatsApp, target 16 MB. For Discord free or Gmail, target 25 MB. For Discord Nitro Basic, target 50 MB.
  • The compressor uses H.264 with constrained rate control. Two compression modes: CRF (target quality, variable size) and target-size (variable quality, fixed size). For sharing within a hard cap, use target size.
  • If you only need to shrink a GIF (not a video), use Compress GIF. If you're converting a video to GIF and need to shrink the result, do the video compress first then MP4 to GIF.
  • FFmpeg one-liner for a target file size: see the math section below.

The platform limits, as of 2026

The numbers move occasionally but the shape is stable. The current hard caps you should plan around:

WhatsApp: 16 MB for video sent through the chat interface. Files larger get rejected. WhatsApp Business has higher limits but the 16 MB cap applies to consumer chats.

Discord free: 25 MB per file upload. Above that, you need a Nitro plan or you have to share a link to the file hosted elsewhere.

Discord Nitro Basic: 50 MB per file.

Discord Nitro: 500 MB per file.

Gmail attachments: 25 MB. Above that, Gmail offers to convert the attachment to a Google Drive link automatically. Some recipients see the Drive link as suspicious or behind a permission wall.

Outlook (consumer): 20 MB.

Outlook (Microsoft 365 business): 33 MB by default, configurable up to 150 MB.

If you don't know where the video will end up, target the smallest cap on the list you might hit. 16 MB covers WhatsApp and most email scenarios. 25 MB covers Discord and Gmail. 50 MB covers Discord Nitro.

CRF vs target bitrate vs target size — the three rate control modes

H.264 has three ways to control the encoded file size, and they're often confused.

CRF (Constant Rate Factor) is the quality-targeted mode. You give the encoder a number from 0 (lossless) to 51 (worst). CRF 18 is visually lossless to most viewers. CRF 23 is the standard default — looks identical to source for most content. CRF 28 is the floor before things look obviously compressed. The encoder then uses whatever bitrate it needs to hit that quality target. The output file size is variable and you find out after the encode is done.

Target bitrate is the average-bitrate mode. You give the encoder a bitrate (say, 2 Mbps) and it tries to hit that average across the video. Quality varies by scene — static scenes look great, fast motion looks worse. Output file size is roughly bitrate × duration.

Target size is what you actually want for hitting WhatsApp's 16 MB cap. You give the encoder a target file size and it works backward to figure out what bitrate to use. This is implemented in FFmpeg as a two-pass encode: pass 1 analyzes complexity, pass 2 distributes bits to hit the target.

The Clipy compressor exposes both CRF mode (for general quality-targeted compression) and target-size mode (for hitting specific caps). Pick target size when you have a hard limit, pick CRF when you just want "smaller, but still looks good."

The math behind target-size compression

To hit a specific file size, you work backward from this equation:

target_total_bitrate (kbps) = (target_size_MB * 8192) / duration_seconds

Total bitrate is video plus audio. Audio at 128 kbps AAC is fine for most use cases. So:

target_video_bitrate (kbps) = target_total_bitrate - 128

For a 60-second video and a 16 MB target, that's (16 * 8192) / 60 = 2185 kbps total, minus 128 for audio, equals 2057 kbps video. That's enough for a clean 720p H.264 encode.

For a 5-minute video and the same 16 MB target, that's (16 * 8192) / 300 = 437 kbps total, minus 128 for audio, equals 309 kbps video. That's not enough for clean 720p — you'll need to drop to 480p or accept visible compression artifacts.

The pattern: the longer the video, the lower the resolution you can afford at a given target size. For WhatsApp's 16 MB cap, you can comfortably ship up to ~60 seconds at 720p, up to ~3 minutes at 480p, or up to ~10 minutes at 360p. Longer than that and the bitrate gets too low for any sensible playback quality.

The Clipy compressor handles this math for you when you pick a target size — it suggests an appropriate resolution and shows you what the resulting bitrate will be. If the math doesn't add up (you want a 30-minute 4K video in 16 MB), it'll tell you the target is unrealistic before wasting your CPU on a doomed encode.

Resolution and frame rate — the other knobs that matter

Beyond the encoder settings, the two biggest levers on file size are resolution and frame rate.

Resolution. 1080p is 2.25x the pixels of 720p, which roughly means 2.25x the bitrate to keep the same per-pixel quality. Dropping a screen recording from 1080p to 720p approximately halves the file size at the same CRF. Dropping from 4K to 1080p approximately quarters it. For a 16 MB target on a 2-minute video, 720p is usually the right resolution.

Frame rate. 60fps is twice as many frames as 30fps. The bitrate impact is less than 2x because consecutive frames are similar and H.264 predicts well across them, but it's still significant — usually 40–60% more bitrate at the same quality. Screen recordings can almost always drop to 30fps without anyone noticing. Webcam footage at 60fps is rarely justified. Gameplay or fast motion footage is where 60fps actually matters for perceived smoothness.

The Clipy compressor offers presets that combine these — "WhatsApp 720p," "Discord 720p 30fps," etc. — so you can hit the right balance without thinking about it. If you need to be more surgical, the advanced settings expose resolution, frame rate, CRF, and target size independently.

What NOT to compress, and why

Three cases where compressing hurts more than it helps.

Already-compressed source. If you have a Twitter video you downloaded with a tool, it's already been through one round of Twitter's compression. Re-compressing it makes it worse with no upside. If you need to hit a smaller size, accept the quality hit but understand you're stacking lossy encodes.

Source you'll need to edit later. If you're going to bring this video into a video editor for cuts, color, or graphics, keep the high-quality original. Edit, then compress at the export step. Compressing first and editing the compressed file means the final export is doubly-compressed.

Source intended for archival. If this is the master copy you might want again in five years, keep the high-quality original somewhere. Compress a working copy for sharing.

The compressor never modifies your input file — it produces a new compressed copy. So you can experiment freely without destroying the original. But it's worth being intentional about which file is your master.

The FFmpeg command line version

For CRF mode (target quality, variable size):

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 26 -preset medium -pix_fmt yuv420p \
  -vf "scale=-2:720" \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

For target-size mode (two-pass encode targeting a specific file size):

DURATION=60  # seconds, get with ffprobe
TARGET_MB=16
VIDEO_BITRATE=$(echo "($TARGET_MB * 8192 / $DURATION) - 128" | bc)

ffmpeg -y -i input.mp4 \
  -c:v libx264 -b:v ${VIDEO_BITRATE}k -pass 1 -an \
  -vf "scale=-2:720" \
  -f mp4 /dev/null

ffmpeg -i input.mp4 \
  -c:v libx264 -b:v ${VIDEO_BITRATE}k -pass 2 \
  -vf "scale=-2:720" \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

The browser tool does both modes without you needing to remember the two-pass dance or compute the bitrate.

After compression, the sanity checks

Before you send the compressed file, three things to verify.

Plays correctly. Open the output in your default player. If audio and video are in sync, motion looks smooth, and the file plays from start to finish without stutter, it's good.

Under the cap. Check the file size against your target. WhatsApp does not refund you bytes for being close — under 16 MB plays, 16.1 MB rejects.

Looks acceptable. For a casual share, CRF 28 or a tight target-size mode might leave visible compression artifacts (blockiness in dark scenes, smudged text). If quality suffers more than the use case warrants, raise the CRF target or accept a bigger file.

The summary path

Open Clipy's video compressor. Drop the file in. Pick a target — "WhatsApp 16 MB," "Discord 25 MB," "Email 25 MB," or a custom size. Download the compressed MP4. The compression runs in your browser; the file never uploads.

For GIF-specific compression use Compress GIF. If you need to convert MP4 to GIF (and the GIF will be huge — be warned), MP4 to GIF handles it but plan to compress the GIF after. If the goal is converting a downloaded animation rather than compressing a video, GIF to MP4 almost always produces a smaller file than the compress-and-keep-as-GIF path.