X (Twitter) video upload specs for AI-generated clips

X's media docs recommend H.264 High Profile video at 30 or 60 fps, 1280x720, 720x1280, or 720x720 pixels, AAC LC audio, and at least 5,000 kbps of video; without X Premium, a Post video can run 0.5 seconds to 20 minutes and 8 GB. Sume's video trim and Timeline 1.0 can set those sizes and frame rates, but not the bitrate or the H.264 profile, so check both before you upload.

X's figures are quoted from its media best practices page, read on 2026-09-27; X can change them. Sume's come from the Video trim, Timeline 1.0, and Video inspect docs, the Sume API reference, and Sume's media compiler as it works today.

What are X's video size and length limits?

Limits follow the posting account's X Premium or verified status, not your developer API plan. Upload and Post creation are checked separately: a finalized video can still be refused by POST /2/tweets, with a 403 when it is too long. Use tweet_video for a regular Post and amplify_video for ads creatives.

Where does X's page contradict itself?

Two pairs of lines on the same page disagree, and the page does not say which one wins:

• Dimensions. The recommended list names 720x1280 as the portrait size and says subscribed users “can upload a 1080p video and get 1080p playback”. The advanced list says dimensions “must be between 32x32 and 1280x1024”, which a 720x1280 or 1920x1080 frame exceeds. Only the landscape 1280x720 and square 720x720 sizes fit both lines.
• Bitrate. The recommended list asks for a minimum video bitrate of 5,000 kbps. The table further down suggests 2048K for 1280x720, 720x1280, and 720x720, and calls each row “an upload recommendation, but is not a requirement”.

How do I conform a Sume clip to X's recommended format?

Generate with aspect_ratio 16:9, 9:16, or 1:1 on a model that lists it; a pixel size returns 400 unsupported_parameter. Every ratio in Sume's video list, 21:9 through 9:21, is inside X's required 1:3 to 3:1 range.

Then conform the finished clip, by its media.sume.com artifact URL from GET /v1/jobs/{id}/result, to one of X's sizes at 30 or 60 fps. Both tools take edges of 256–2160 pixels:

• One clip: POST /v1/video-trim with output: { width, height, fps }; kept audio is written as AAC. The request below makes a 12-second clip 1280 pixels tall at 30 fps. That is X's 720x1280 portrait size when the source is exactly 9:16, because today a lone height lets the width follow the source's aspect ratio.
• Several clips: POST /v1/timeline-1.0/render with even output.width and output.height, plus output.fps. Its default cover fit fills the frame and crops the overflow, and its sound comes from the render's audio spine, not the clips. Change a video's frame rate or resolution covers both tools.

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: x-portrait-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/clip.mp4",
    "start": 0,
    "duration": 12,
    "output": { "height": 1280, "fps": 30 }
  }'

Which of X's encoding lines can I not set in Sume?

Trim and Timeline refuse encoder fields such as codec and crf, so these lines are checked, not set. YouTube Shorts video specs compares Sume's encode setting by setting; against X's lines it stands like this:

How do I check a clip before I upload it to X?

Run POST /v1/video-inspect with frames: false, an unbilled probe-only inspect. It reports width, height, fps, duration_seconds, video_codec, pix_fmt, audio_codec, audio_channels, audio_sample_rate, and size_bytes, but no profile or bitrate. Average bitrate, audio included, is size_bytes × 8 ÷ duration_seconds; compare it with X's 5,000 kbps video line. Get a video's duration, resolution, and fps shows the probe call.

Then upload from your server with the chunked flow X says to use for all videos: POST /2/media/upload/initialize, /{id}/append, then /{id}/finalize. For stills, POST /v1/images writes png, jpeg, or webp on models that list them, all types X accepts; check each file against X's 5 MB image cap.