Compress a video for X (Twitter)

The limit that stops you is duration, not size

X caps two things: how long the video runs and how large the file is. For most people it is the clock that bites. The free tier has been held to a couple of minutes for years, an inheritance from the era when everything on the platform was small, and the paid tiers raise it far enough that the real question becomes whether anyone will watch that long.

The size cap is comparatively generous, and it is not the same in the web uploader as it is in the mobile apps. Rather than trust a figure written on a page, put the file into the composer you actually post from. It refuses an over-long or over-large video immediately and names what it will take, which is both quicker and more current than any published list.

That inversion is worth sitting with, because it is the opposite of the Discord case. There you compress to fit. Here you almost never do. You compress because a smaller file uploads faster and because the transcoder does better work on a clean input, and you trim because the clock is the wall you actually hit.

Nothing you upload is what anybody plays

X transcodes every upload into several renditions at different resolutions and bitrates, and the player chooses between them based on the viewer's connection and how large the video is on their screen. Your file is the input to that process and nothing else. It is not stored and served; it is decoded, re-encoded, and set aside.

This is the entire explanation for the complaint that a video "looks worse on X". You are not comparing your export against itself. You are comparing it against a re-encode of it, made at a bitrate you did not choose, by an encoder tuned for delivery cost rather than for your footage. No upload setting on your end opts out of that.

What you do control is what the second encoder sees. Hand it a file that is already full of blocking and mosquito noise and it will preserve those artefacts faithfully, as though they were detail, spending bits on your compression damage instead of on your picture. Compress gently here, or not at all if the clip is short enough to go up untouched.

Why 720p is the practical ceiling

A 1080p rendition exists. Most viewers never see it. Video on the timeline plays in a column a few hundred pixels wide on a phone and not dramatically wider on a desktop, and the player is picking a rendition to suit that, over a connection it is guessing about. Uploading 4K is not wrong so much as it is spent on nobody.

Exporting at 720p instead has a second effect that matters more than the first. Your own budget is spread across 44% as many pixels, so the file you hand over is cleaner at the same size and the transcode starts from a better place. A clean 720p source usually survives the round trip better than a starved 1080p one.

Frame rate is the other lever and it is larger than people expect. Sixty frames a second is twice as many pictures to describe as thirty, paid for out of the same budget. Unless the motion is the point, export at 30 and give every frame twice the bits. If your capture software can record at 30 in the first place, better still.

It plays muted, and text is the first thing to go

Video autoplays without sound in the timeline. A large share of the people who see your clip never turn it on, so anything carried entirely by the audio is carried by nothing. Burn the captions in rather than leaving them to the platform.

Then make them bigger than feels necessary. Thin white type over a moving background is close to the worst case for a bitrate-limited encoder: the edges are high contrast and high frequency, the background behind them keeps changing, and fine detail of exactly that kind is the first thing rate control gives up on. Type that looks slightly oversized on your monitor looks correct in a phone-sized player after two rounds of compression.

Settings for a clip going to X

MP4 with H.264 video and AAC audio. 720p unless the frame is full of text somebody has to read. Target-size mode at 50 MB or below, which across a two-minute clip works out to a few thousand kilobits per second, comfortably enough that the transcoder is not being handed damage to preserve. The target-size pages cover how that budget gets solved.

Trim before you compress, always. It is the only reduction that costs nothing: fifteen seconds cut from the front is fifteen seconds of bitrate returned to the part people stay for, and it is the only edit that helps against the duration cap as well. What bitrate is, and how it turns into file size covers the arithmetic under all of this.

Questions about X (Twitter)

Elsewhere on the site

X (Twitter) is one of 7 destinations with a page here, and the other 6 differ from the X (Twitter) page only in the ceiling the compressor opens at and in what that particular platform does to your file after you send it. The full list is here, or jump straight to one:

• Discord
• WhatsApp
• email
• Reddit
• Telegram
• Slack

Or go straight to a size ceiling:

• 5 MB
• 8 MB
• 10 MB
• 16 MB
• 20 MB
• 25 MB
• 50 MB
• 100 MB
• 200 MB
• 500 MB