Compress a video for Slack

What Slack publishes

Add files to Slack says you can add files up to 1 GB, drag up to 10 files into one message, and that uploads are scanned for malware, so bigger files take longer to become available. Uploads may be restricted in Slack Connect conversations. Slack's file sharing page adds that the Free plan keeps files for 90 days and other plans keep them without a time limit.

On 29 October 2026 that help article said “Members and guests can add files up to 1GB in size,” “Drag and drop up to 10 files into the Slack message field,” and “Files you add to Slack will be scanned for viruses and other malware, and won't be uploaded if any are detected.”

This site has no measured Slack lab, so nothing below claims how Slack re-encodes or previews video. The measurements are about the file you hand to Slack.

A high-bitrate synthetic that got smaller

The screen recording above grew. A different file, a 12 second 1280×720 noisy test pattern, got smaller under ffmpeg 6.1.1-3ubuntu5. The source command used libx264 ultrafast at 25000k video, minrate 22000k, maxrate 25000k, bufsize 25000k, and AAC at 160k. The output command used libx264 medium at 800k video, maxrate 800k, bufsize 1600k, AAC at 96k, and +faststart. The compressor button was not used. 38452098 bytes is under 1 × 1,000,000,000.

The output is smaller: 38452098 bytes in, 567974 bytes out. ffprobe duration on the output is 12.010000 seconds. The record is docs/evidence/runs/2026-10-29-comp-fixtures.json.

A screen recording that got bigger

Every measured number on this page comes from one run set on 2026-10-18: the live /tools/video-compressor/ page driven by headless Chrome/154.0.8037.92 on 13th Gen Intel(R) Core(TM) i9-13900K (32 threads, 126 GB RAM, Linux 7.0.0-34-generic), software WebCodecs with no GPU. The sources are synthetic files made with ffmpeg (ffmpeg version 6.1.1-3ubuntu5): a test pattern, with temporal noise added where the label says noisy, plus a 48 kHz sine tone. They are not camera footage. Outputs were saved through the page's Save button and measured with ffprobe. The raw records are in the repository at docs/evidence/runs/2026-10-18-video-target-runs.json. A phone or a machine with a hardware encoder can land at different sizes, and that was not measured.

Why that happens

The source here is five minutes of a dark window with a moving rectangle and a ticking clock, encoded by ffmpeg at 16.7 MB. That is about 0.47 Mbps, already tight for static content. The Smallest preset wrote VP9 in WebM at 1920×1080 (it caps the height at 1080) and returned 22.7 MB, larger than the file it started from. The result card showed the saving as "0 B · 0.0%". The Balanced run with a 10 MB target kept 2560×1440 H.264 and returned 12.3 MB, about 27% under the source, and still over the 10 MB target.

A recording made by an OS screen recorder is usually written at a fixed high rate, so it compresses far more than this synthetic one. The lesson is to look at the Saved line on the result card and keep the original when it shows nothing saved.

One more run in this set did not finish: Balanced with no target on the same recording did not finish in two attempts and is left out of the table. It is recorded as a failure in the evidence file.

When to compress for Slack at all

Under 1 GB there is no size reason. Compress when a teammate will play the clip on a slow connection or when a recording runs over the cap. For the cap, cut the clip first, then compress.

The MP4 files the compressor wrote still carry container tags (major_brand, minor_version, compatible_brands, creation_time). The creation_time value is the time of the encode, not of the original recording. For a file you plan to publish, run the output through Verify metadata removed and read Remove MP4 metadata. Open the Video Compressor, or read the video compression guide.

FAQ

More tools

Video Compressor · Video size limits by platform · Video compression guide · Remove MP4 metadata · Verify metadata removed