Compress Video for X: Under the Upload Limits
By Mark Fulton · 2026-09-21 · 10 min read
X's video size limit for an account without Premium is 512 MB and 140 seconds per upload, according to X's own Help Center as of 21 September 2026. Premium raises that to 16 GB and up to 4 hours. But size is almost never the reason a video gets refused. A 140 second clip would have to average more than 29 Mbps to reach 512 MB, which is above the 25 Mbps bitrate ceiling X lists for web uploads. When an upload to X fails, the cause is usually length, frame rate, codec, pixel format or the audio track. One re-encode to 720p H.264 with stereo AAC audio, trimmed to 140 seconds, clears every one of those at once.
That last sentence is the useful part, and it is the part most spec tables leave out. They print a generous file ceiling, you check your file against it, it passes, and the upload still fails. The rest of this page is about why that happens and how to fix it.
What are X's current video limits?
X publishes its video rules in two places, and they do not fully agree. The Help Center page on sharing videos covers the app and x.com. The developer media best practices cover uploads through the API and go much deeper into codec requirements. Both were read on 21 September 2026 for this table. Every row should be checked against those pages again before you rely on it, because X changes these numbers without much announcement.
| Spec | Without Premium | With Premium | Source |
|---|---|---|---|
| Length per video | 140 seconds (Help Center) | Under 4 hours; 2 to 4 hours must be 720p (Help Center) | Verify at upload time |
| File size | 512 MB (Help Center) | 16 GB (Help Center) | Verify at upload time |
| Playback resolution | 720p upload, 720p playback | 1080p upload, 1080p playback | Developer docs |
| Maximum upload resolution (web) | 1920 x 1200, or 1200 x 1900 portrait | Same | Help Center FAQ |
| Minimum resolution | 32 x 32 | Same | Both |
| Aspect ratio (web) | 1:2.39 to 2.39:1 | Same | Help Center FAQ |
| Frame rate | 40 fps maximum (web FAQ); 60 fps or less (developer docs) | Same | Verify at upload time |
| Bitrate | 25 Mbps maximum (web FAQ) | Same | Help Center FAQ |
| Video codec | H.264, High Profile recommended | Same | Developer docs |
| Pixel format | YUV 4:2:0 only | Same | Developer docs |
| Audio | AAC LC (not HE-AAC), mono or stereo, not 5.1 | Same | Developer docs |
| Structure | Progressive scan, no open GOP, square pixels | Same | Developer docs |
Two disagreements are worth knowing about. First, the developer docs list a default Post video cap of 20 minutes and 8 GB, and 125 minutes and 16 GB for Premium, and say those caps match the app. The Help Center still says 140 seconds and 512 MB for anyone without Premium. When the two conflict, plan for the stricter one: 140 seconds. Second, the web FAQ caps frame rate at 40 fps, while the developer docs recommend 30 or 60 fps. A 30 fps file satisfies both.
Why does a file inside the size limit still fail?
Because the size ceiling is the loosest rule on the list. Here is the arithmetic. 512 MB is 4,096 megabits. Spread over 140 seconds, that allows an average of about 29 Mbps for video and audio together. The web FAQ caps bitrate at 25 Mbps, and a full 140 seconds at 25 Mbps comes to roughly 437 MB. So a file that respects the bitrate cap cannot exceed the size cap at the free length limit. If your clip is under 512 MB and still refused, something other than size is almost certainly the problem. The full reasoning behind size equals bitrate times duration is in how to compress a video to an exact file size.
These are the failures that actually cause refusals, roughly in order of how often people run into them:
| What went wrong | Where it usually comes from | The fix |
|---|---|---|
| Longer than 140 seconds | Any clip, on an account without Premium | Trim it, or split it into parts |
| Frame rate above 40 fps | Phone footage at 60 fps, game captures, screen recordings | Re-export at 30 fps from the source app |
| Codec other than H.264 | HEVC from recent iPhones, VP9 or AV1 in WebM, ProRes | Re-encode to H.264 |
| 10-bit or 4:2:2 pixel format | HDR phone video, log footage, pro camera files | Re-encode to 8-bit 4:2:0 |
| 5.1 surround or HE-AAC audio | Some camera, editor and screen recorder exports | Export stereo AAC from the source, or mute |
| Resolution above 1920 x 1200 | 4K and 1440p footage | Downscale |
| Aspect ratio past 2.39:1 | Ultrawide captures, very tall vertical crops | Crop to a standard ratio |
| Bitrate above 25 Mbps | Camera originals, high quality screen captures | Compress |
| Interlaced or open GOP | Broadcast cameras, some editing exports | Re-encode |
One oddity is worth flagging. A standard vertical phone video is 1080 x 1920. Taken literally, the web FAQ's portrait maximum of 1200 x 1900 is 20 pixels shorter than that. The documentation does not say whether the uploader enforces it that strictly. For an account without Premium it does not matter anyway: playback tops out at 720p, so downscaling a vertical clip before you upload costs nothing that anyone will see.
What resolution and frame rate should you export?
For an account without Premium, 720p at 30 fps. The developer docs say it directly: unsubscribed users upload 720p and get 720p playback. A 1080p or 4K upload does not look sharper on the timeline. It takes longer to upload, and X's encoder has to throw the extra pixels away. X's own recommended sizes are 1280 x 720 for landscape, 720 x 1280 for portrait and 720 x 720 for square, and its table of recommended bitrates pairs 1280 x 720 with 2,048 kbps of video and 128 kbps of audio. Those rows are labelled as recommendations, not requirements.
With Premium, 1080p is worth keeping because X will serve it at 1080p. Anything past 1080p is still wasted.
Frame rate is simpler than it looks. 30 fps passes the web cap of 40 and the developer limit of 60. If the footage is gameplay or fast sport where 60 fps smoothness is the point, the developer docs say 60 is acceptable. The web FAQ lists 40 as its maximum, so a 60 fps upload that fails on x.com is the first thing to suspect.
Aspect ratio is its own question. 16:9, 9:16 and 1:1 all sit comfortably inside X's range. If a clip is outside it, crop it to one of those rather than squeezing it. The trade offs between the common ratios are covered in video aspect ratios explained.
Does X re-compress your upload?
Yes, always. The developer docs state that all uploads are processed for optimization across multiple platforms. Every video you post is decoded and re-encoded by X before anyone sees it, whatever you send.
That changes the goal. You are not trying to make the smallest possible file, and you are not trying to preserve every bit of the original either. You are trying to hand X's encoder a clean, efficient source at the resolution it will actually deliver. A heavily compressed input arrives with blocking and smearing already baked in, and a second lossy encode keeps those artifacts and adds its own. MDN's web video codec guide explains the underlying point: lossy codecs discard detail that cannot be recovered, and more compression means more loss. Each generation compounds the last.
In practice, that means a 720p file at a good quality setting beats a 1080p file squeezed hard to save space. Fewer pixels at a decent quality give X's encoder something clean to work from. The same logic applies to codecs. H.264 is the only codec X names, so a phone's HEVC file needs converting first. Why phones default to HEVC, and what it costs to convert, is in H.264 vs H.265.
How do you fix a rejected video in one pass?
Most of the failures in the table above are fixed by one encode, because the encode itself produces what X asks for. Every re-encoding tool on this site writes H.264 video in 8-bit YUV 4:2:0 with AAC-LC audio in an MP4. We checked the output with ffprobe while writing this: High Profile H.264, yuv420p, AAC LC. That one pass takes care of the codec, the pixel format, the audio profile, the GOP structure and the scan type.
The order that keeps it to one lossy encode:
- Check the length first. If the clip runs past 140 seconds and you don't have Premium, trim it. Pro's instant trim copies the streams without re-encoding, so it adds no quality loss. On the free tier, trim is a re-encode of its own, so trim first and then do the rest in the next pass.
- Resize to 720. The resize tool scales by height and only ever downscales. On landscape footage, 720 gives you 1280 x 720. On a vertical 1080 x 1920 clip it gives 720 tall and about 406 wide, which is well inside X's limits but smaller than X's recommended 720 x 1280. If you want to keep that portrait size, skip resizing and let the compressor re-encode at full resolution instead. This single encode also converts the codec, the pixel format and the audio.
- Or compress, if the resolution is already right. The compressor re-encodes at the same resolution. Its high setting is the one to choose for X, because X is going to compress the file again. You are not fighting a small size cap here.
- Or convert, if only the format is wrong. An iPhone HEVC file or a WebM that is otherwise fine only needs converting to MP4, which re-encodes to H.264 at a high quality setting.
Two things one pass here will not change, so check them in the source app. These tools keep the source frame rate, so a 60 fps clip stays 60 fps. If x.com refuses it, export at 30 fps from your camera, recorder or editor. They also keep the audio channel layout, so a 5.1 track stays 5.1 and X's docs rule that out. Export stereo from the source, or mute the clip if the sound doesn't matter.
All of this runs in the browser tab. The file is read into memory and processed on your own machine by ffmpeg compiled to WebAssembly, so the video is never uploaded anywhere except, at the end, to X itself. The honest limits: the free tier accepts files up to 200 MB and adds a small corner watermark to video exports, and because your own CPU does the encoding, a long clip takes as long as your computer takes. Pro, at $4 a month billed $24 every six months or $79 once, removes the cap and the watermark and adds lossless instant trim and compression to an exact file size.
Frequently asked questions
How long can an X video be?
On an account without Premium, X's Help Center puts the limit at 140 seconds, or 2 minutes 20 seconds, as of 21 September 2026. With Premium you can upload videos under 4 hours long, and anything between 2 and 4 hours must be 720p. X's developer documentation lists longer defaults (20 minutes without Premium, 125 minutes with it), so the limit you actually get may be higher. Plan for 140 seconds unless your own upload screen shows otherwise.
Why does my video fail to upload to X?
Usually not because of size. The common causes are a clip longer than 140 seconds, a frame rate above 40 fps on the web uploader, HEVC or another codec that isn't H.264, 10-bit HDR video, 5.1 surround audio, or a resolution above 1920 x 1200. Re-encoding to 720p H.264 with stereo AAC audio at 30 fps fixes nearly all of them together. Trimming fixes the length.
Does X compress videos?
Yes. X's developer documentation says every upload is processed for optimization across multiple platforms, so your video is always re-encoded after you post it. Accounts without Premium get 720p playback however large the upload is. The best input is a clean 720p H.264 file at a good quality setting, which leaves X's encoder little to damage.
What format does X accept?
H.264 video with AAC-LC audio is the only combination X's documentation names. The Help Center adds that x.com warns you if a file isn't in a supported format. An MP4 with H.264 video, 8-bit 4:2:0 color, and mono or stereo AAC audio is the safe choice. If your file is HEVC, WebM or ProRes, convert it to MP4 first.
Trim it to length, convert and compress it to spec here, then upload once. Nothing leaves your machine until you post it, and the rest of the tools work the same way.
Sources
- X Help Center, How to share and watch videos on X
- X Developer Platform, Media best practices: video specifications and recommendations
- MDN Web Docs, Web video codec guide