2026-07-29

GitHub, Discord, and Slack GIF upload limits in 2026 (and why trimming comes before converting)

You trimmed a bug repro or a feature demo down to a few seconds, converted it to a GIF, and the upload got rejected anyway. The three places developers post these clips most — GitHub, Discord, and Slack — each enforce their own size cap, and two of the three changed their numbers within the last two years. Here are the current, sourced limits, and the actual biggest lever for staying under them, which has less to do with GIF quality settings than with how much footage you fed the encoder in the first place.

The three limits that actually apply right now

As of mid-2026:

• GitHub: 10MB for images and GIFs. GitHub's own docs on attaching files to issues, pull requests, and comments are explicit: "10MB for images and gifs," "25MB for all other files," and for actual video files, "10MB for videos uploaded to a repository owned by a user or organization on a free GitHub plan" versus "100MB" on a paid plan. Since a plain git repo has no built-in "upload a media asset" button, the common workaround for putting a GIF in a README is to drag it into a new issue or pull request comment box first — GitHub generates a hosted URL for the file that you can then paste into the README's Markdown, even though the file itself was never actually attached to that issue. That URL still has to clear the same 10MB images-and-GIFs limit, because it's the same upload path.
• Discord: 10MB for free users, since September 2024. Discord's own product account announced the change directly, lowering the free-tier cap back down from 25MB to 10MB — reporting at the time (Dataconomy, Dexerto) cited Discord's stated reasoning that "storage management is expensive" and that the vast majority of users' files were already under 10MB anyway. Nitro Basic raises the cap to 50MB, and full Nitro to 500MB. One detail worth knowing: the cap applies to the combined size of everything attached to a single message, not per individual file — a handful of small GIFs dropped into one message share that same 10MB budget.
• Slack: 1GB per file, on every plan including Free. Slack's own help center states files can be up to 1GB each, with no lower cap called out for the Free plan — so raw file size is rarely what blocks an upload there. The real catch on Slack Free is retention, not size: Slack's own documentation says the free plan surfaces only the most recent 90 days of message and file history, and data older than a year gets deleted on a rolling basis. A demo GIF shared on Slack Free eight months ago may already be gone by the time someone goes looking for it — a different failure mode than "the upload got rejected," but one that matters if you're linking back to it later.

Why a GIF blows past a video's budget at the same footage

The GitHub numbers above are a clue on their own: a video gets 10MB (free) or 100MB (paid), but an image or GIF of the exact same dimensions is capped at 10MB regardless of plan. That gap exists because GIF and modern video codecs solve compression completely differently. A video codec like VP9 or H.264 spends most of its bits predicting each frame from the ones around it — only the parts of the picture that actually changed get re-encoded. GIF has no equivalent inter-frame prediction; it's built around a per-frame, limited-palette approach designed for the 1987 web, not for smooth motion. The same eight seconds of screen recording can end up meaningfully larger as a GIF than as a WebM or MP4 of visually the same content, which is exactly why a clip that comfortably clears a platform's video-upload cap can turn around and get rejected the moment it's converted to GIF for a spot that only accepts still-image-style attachments.

The lever that actually matters: trim before you convert

NearVid's trim is a lossless stream copy, not a re-encode — cut the recording down to just the seconds that actually show the bug or the feature before generating anything else. That ordering matters more than it looks: a GIF or WebM encoder has to spend output bytes on every single frame it produces, so input duration is the single largest input to the final file size, well ahead of any per-frame quality setting you might tune afterward. Trimming a 40-second screen recording down to the 8 seconds that matter, then converting, produces a file a fraction of the size of converting the whole 40 seconds and hoping the result squeaks under the cap — and it costs nothing extra to do first, since NearVid's trim only copies the container, it doesn't decode or re-encode a frame.

Where the destination actually accepts a real video attachment instead of an animated image — Discord's file attachments and Slack's file uploads both do — converting the same trimmed clip to WebM instead of GIF is usually the more size-efficient choice, for the reason above: motion-aware video compression handles the same footage far more efficiently than GIF's per-frame approach. Save GIF for the specific spots that need an animated image rather than a video file — an inline README animation with no <video> embed, or a chat context that only previews images inline. And on Chrome or another Chromium-based browser with WebCodecs support, NearVid can export a real MP4 from the same trimmed clip instead, for destinations that expect a conventional video container rather than WebM — that path is feature-detected and isn't available in every browser, so it's worth checking it actually produced an MP4 rather than assuming it did.

What NearVid actually does and doesn't do here

To be specific about scope: NearVid doesn't know about GitHub's, Discord's, or Slack's specific caps, and it doesn't target a byte count for you — there's no auto-resize or auto-bitrate slider that promises "under 10MB." You trim to length, convert to GIF, WebM, or (where supported) MP4, and then check the resulting file's size yourself against whichever limit applies to where you're posting it. What it does do is run all of that — trim, WebM/GIF conversion, conditional MP4 export, and still-frame extraction for a cover image — entirely on-device in the browser tab, so producing the smaller file doesn't require uploading the larger original anywhere first.

The honest summary

The current numbers: GitHub caps images and GIFs at 10MB regardless of plan (10MB/100MB for actual video files, free versus paid); Discord dropped its free-tier cap from 25MB to 10MB in September 2024, with Nitro Basic and full Nitro at 50MB and 500MB; Slack allows files up to 1GB on every plan but only keeps free-plan history for 90 days to a year. None of those numbers move if you fiddle with GIF quality settings after the fact — the input duration you hand the encoder does more work than any setting downstream of it, which is why trimming to exactly the seconds that matter, before converting to anything, is the step worth doing first.