X API Video Upload Limit: Three Official Numbers, All Correct

Here is a question that ate most of a working day. How long a video can you upload to X? We had three official answers open in three tabs, all current, all from x.com, and no two of them agreed. One said a couple of hours. One said 125 minutes. One said 140 seconds.

The obvious conclusion was that somebody at X had forgotten to update a page. That conclusion was wrong, and the relief when it dissolved was out of all proportion to the size of the finding — because the thing that dissolved it is a rule you can reuse on every platform you touch.

Three tabs, three answers to one x api video upload limit

The x api video upload limit is one of those specs that seems like it should be a single sentence. It isn't, and the reason people burn hours on it is that they go looking for the number. Here is what we actually had open:

• The consumer help pages, describing what a Premium subscriber can upload in the app — roughly three to four hours, depending on which of the two pages you land on. The two pages themselves disagree, one pairing about three hours with 8 GB and the other about four hours with 16 GB.
• The API documentation, describing what you can attach to a post you create programmatically — 125 minutes for a Premium account.
• The direct-message documentation — 140 seconds.

Three numbers spanning a factor of roughly a hundred. If you assume they are competing answers to one question, the only available move is to guess which page is freshest, and that guess is how people end up writing an uploader that works in testing and throws on the first real file.

The sentence in the changelog that dissolves it

The X API changelog entry dated 1 September 2026 carries the line that makes all three numbers correct at once. Two clauses do the work:

"Limits follow the authenticated user's X Premium / verified status and media_category, not your developer API plan." And: "Upload and POST /2/tweets are separately enforced."

Read that slowly, because it quietly demolishes two assumptions most people bring to the problem. First, the ceiling is not a property of your developer tier — it is a property of the account whose credentials you are posting with, plus the media_category you declared. Paying X more as a developer does not buy you a longer video. The account holder's Premium status does. Second, getting the bytes up and getting the post created are two separate gates. A file can finish uploading and still be refused at post time, which is exactly the failure mode that makes this feel like a platform bug rather than a documented rule.

Once you accept that framing, the three numbers stop competing and simply describe three places you can send a video:

Exceed the post-creation ceiling and X does not hand you a spec. It hands you a 403 carrying the text This user is not allowed to post a video longer than N minutes. That error message is worth pausing on, because it is where most of the folklore about X video limits comes from. A number that only appears at the moment something fails is a boundary, not a policy — it can move with the account, and it was never written for you to plan against.

One practical footnote while you are in there: the chunked upload quickstart now lives on v2 paths. Initialize, append, finalize are POST /2/media/upload/initialize, then /{id}/append, then /{id}/finalize. If you are following a tutorial that still uses the older media endpoint, that is a separate afternoon you do not need to lose.

The rule worth stealing: count the surfaces before you compare the numbers

Here is the part that generalises. We had already learned that when two official pages disagree, the honest first question is not "which one is stale" but "are these two different product lines with two different documentation owners". X gave us the third surface on the same platform, which turns a tiebreaker into a counting exercise:

Before you compare two official numbers, count how many product surfaces the platform has. Most of the contradictions you will find are not contradictions — they are a table you have only seen one row of.

A four-step version you can run in about five minutes on any platform, not just X:

1. Name your upload path out loud. Consumer app, official API, direct message, ads system, third-party tool riding one of those. This single sentence eliminates most wrong numbers before you read anything.
2. Check whether the limit keys off the account or off your plan. X keys off the authenticated user's Premium status. Assuming it keys off your developer tier is the expensive mistake.
3. Assume the gates are separate. Upload succeeding tells you nothing about publish succeeding. Test the full path with a file near your real ceiling, not a 10-second sample.
4. When two numbers still disagree, plan by the more conservative one. Planning by the generous number means discovering you were wrong at the worst possible moment — mid-publish, on a deadline.

There is a corollary for anyone publishing through a browser rather than an API, which includes most multi-account operators. If your tool drives a real logged-in session — the approach browser-based automation takes, and the one NoobClaw uses as an AI matrix growth engine, signing in to your own accounts locally rather than holding your credentials — then you are on the consumer surface, not the API surface. Your ceiling is whatever that account's Premium status allows in the app, and the 125-minute API figure is simply not your number. That is not a limitation so much as a different row of the table, and knowing which row you are in is the whole point.

FAQ

Does paying for a higher X API tier let me post longer videos?

No. The changelog is explicit that limits follow the authenticated user's Premium or verified status and the declared media_category, not your developer API plan. If you need the 125-minute ceiling, the account you are posting as needs Premium. Upgrading your own developer access does nothing for video length. It does affect other things — request volume and endpoint access — which is a separate budget question covered in the free-tier limits breakdown and the per-post cost math.

My upload finished but the post was rejected. Is that a bug?

Almost certainly not. Upload and post creation are separately enforced, so a file can transfer completely and then be refused at publish time. Look for a 403 with the text about not being allowed to post a video longer than N minutes. Treat that N as a symptom of the account's status, not as a spec to build against.

Which number should I design my pipeline around?

The most conservative number on your actual path. If you publish through the API with ordinary accounts, design for 20 minutes and 8 GB and treat anything beyond it as a feature that requires the account to be Premium. If you cut long videos into short vertical posts anyway — as most multi-platform workflows do, see bulk video uploading — none of these ceilings will ever be your binding constraint, and you can stop worrying about them entirely.

The satisfying part of this one is how little you have to remember. Not three numbers. One question: which surface am I on? Ask it first and the documentation stops contradicting itself.