2026-08-15

X and Bluesky video length limits in 2026 (and how to trim once to fit both)

If you post the same clip to both X and Bluesky, the two platforms don't agree on much. X's free tier and Bluesky both cap video length in the low minutes, but the exact numbers, the file-size ceilings, and even which container format they'll accept are different enough that a clip built for one can get rejected — or silently re-compressed harder than you'd like — on the other. Here are the current, sourced limits for both, and the trim-first order of operations that gets one clip ready for whichever cap is tighter.

What X allows, straight from its own Help Center

• Free accounts: X's own Help Center caps an uploaded video at 140 seconds (2 minutes 20 seconds) and 512MB. That number has held for years — it predates the rebrand from Twitter — so if you're going by a length limit you remember from a while back, it's worth confirming it's still 140 seconds, not something you're misremembering as higher.
• Premium subscribers: a separate Help Center page raises that ceiling considerably — up to 4 hours long, up to 16GB, at 1080p for anything under 2 hours (2-4 hour videos need to be 720p instead). That's a subscription gate, not a free-tier number, so don't plan around it unless you're actually paying for it.

What Bluesky allows, and how recently it changed

• Length: Bluesky's video feature is younger than X's — it launched with a 60-second cap in September 2024, per TechCrunch's coverage at the time. That ceiling tripled to 3 minutes (180 seconds) in the app's version 1.99 update, which TechCrunch and gHacks both reported on March 10-11, 2025 — the current cap, as far as any source checked for this piece shows.
• Format: Bluesky's own protocol source is unambiguous here. The app.bsky.embed.video lexicon, in the actual bluesky-social/atproto repository on GitHub, declares "accept": ["video/mp4"] — MP4 only, nothing else, straight from the schema the app itself is built on.
• Size: that same lexicon file declares a raw maxSize of 300,000,000 bytes (≈286MB) for the embed record, but that's a protocol ceiling, not what a real upload actually gets through in practice — a still-open issue on the bluesky-social/social-app repo is a user running into the app's real, lower, enforced cap and quoting the exact error it throws well before that 300MB schema limit. The number that keeps showing up as what actually blocks an upload is 100MB — treat that as the practical target, not the 300MB figure buried in the schema.

Why trimming first, not converting first, is the move

NearVid's Trim card describes itself plainly in the app: "Cut a clip without re-encoding — fast, lossless, keeps the original format." That's the operation to reach for before anything else here. Getting a clip under 140 seconds for X's free tier, or under 180 for Bluesky, doesn't need a single frame re-encoded — trim is a stream copy, so cutting it down costs no quality and takes well under a second for most files. If your source is already an MP4 (which most phone recordings and screen captures are), a plain trim is often the entire job: same container, same codec, just shorter, and already the one format Bluesky's lexicon actually accepts.

What NearVid actually does when size, not just length, is the binding constraint

Length and size don't always move together. Run NearVid's own numbers and the gap becomes concrete: at the MP4 High quality preset, a full 180-second clip — Bluesky's exact ceiling — lands around 88.6MB, comfortably (if not enormously) under that platform's ~100MB practical cap. Drop to Medium and the same 180 seconds is about 45.7MB; Low brings it to roughly 19.9MB. On X's free tier, the 140-second ceiling makes size close to a non-issue at any preset — even MP4 High only reaches about 68.9MB, nowhere near the 512MB line. In other words: on Bluesky, a long clip at the highest quality preset is worth checking before you upload; on X's free tier, length is really the only limit you need to watch. Those aren't estimates you have to do by hand — a small "≈" figure next to the Quality dropdown on NearVid's MP4 export screen shows the expected output size live, as you adjust the preset or the trim range, before you commit to the re-encode. It's a labeled approximation (bitrate × duration, computed instantly, not a live test encode), not a guarantee down to the byte, but it's exactly the number worth checking against Bluesky's 100MB before you hit Process.

To be specific about scope: "Convert to MP4" is a real re-encode using your browser's own built-in H.264 + AAC encoder via WebCodecs, and it's currently only available on Chrome and other Chromium-based browsers with that encoding support — NearVid checks this automatically per file and per browser rather than guessing from the browser's name, and simply doesn't show the MP4 card when it isn't available. Trim has no such restriction: the lossless stream-copy path works on any browser, for any source format, precisely because it never touches the encoder at all.

The honest summary

The numbers as of mid-2026: X's free tier caps video at 140 seconds and 512MB, per its own Help Center; X Premium raises that to up to 4 hours and 16GB. Bluesky caps length at 3 minutes (180 seconds), a limit that only went into effect in March 2025, accepts MP4 only per its own protocol source, and enforces a real-world size cap around 100MB well below the 300MB written into its schema. None of those numbers come from NearVid — they're each platform's own current rules, worth rechecking if you've been going by what you remember from a year or two back. What NearVid actually changes is how you get there: trim losslessly to fit the tighter length cap first, at zero quality cost, and only re-encode with a quality preset — checking the "≈" size estimate against whichever platform's number is actually binding — when the source itself needs to shrink too.