Can You Upload WebM to X (Twitter)? What the Docs Say

X has no single published list of accepted video formats, so "can I upload a WebM" has no single official answer — it depends on which upload path you mean. WebM appears by name in exactly one place in X's documentation: the API's upload parameter schema. The help center never lists any format at all, and Media Studio publishes a two-item list that excludes WebM and says, in its own words, that it does not apply to the web composer.

That is not a technicality. It is the whole answer, and it is why people find contradictory claims about WebM on X within minutes of searching.

The three official pages, and what each one covers

The API schema's media_type enum, quoted from the OpenAPI definition, is this:

video/mp4
video/webm
video/mp2t
video/quicktime
text/srt
text/vtt
image/jpeg
image/gif
image/bmp
image/png
image/webp
image/pjpeg
image/tiff
model/gltf-binary
model/vnd.usdz+zip

So video/webm is there. So is video/mp2t (MPEG transport stream) and video/quicktime (MOV). But read what that list is: the set of values the API's initialize request will accept in one parameter. It is the schema for a field in an HTTP request, not a statement about what the composer on x.com will take from your file picker.

Why an API enum is not a "supported formats" list

X's own documentation draws this boundary twice, and both quotes are worth having.

First, Media Studio scopes itself out explicitly. The Media Studio Library FAQ opens its upload specifications with: "These instructions are only valid for Media Studio, and should not be followed for usage of the X developer API, Pro Media API, desktop upload, or mobile upload." That sentence rules the .MP4, .MOV list out as an answer for the web composer — in either direction. It is not evidence that WebM is rejected on the web, and it is not evidence that it is accepted.

Second, the API documentation is clear that getting a file in is a separate gate from getting it posted. In its words: "Upload limits and Post-create limits are separately enforced. A media_id that finalized successfully can still be rejected by POST /2/tweets." The same page explains that the media category you declare changes the rules applied: "The Media Category parameter defines the use case of the media file to be uploaded, and can affect file size limits or other constraints enforced for media uploads."

Two-stage validation is the mechanism behind the most confusing failure mode on X — a progress bar that reaches 100% and then errors. An accepted MIME type at initialize does not promise a successful post.

What to do if your file is a WebM

Given what is actually documented, the defensible move is to hand X the container that every X page that does name a format agrees on. Media Studio says .MP4, .MOV. X Ads says "File types: MP4 or MOV". The API's media best-practices page recommends "Video Codec: H264 High Profile". No official page recommends WebM for any upload path.

This converts in your browser tab — the file is read from disk, re-encoded locally, and handed back. Nothing is uploaded to a server, which matters when the whole point is getting a file past someone else's upload limits.

If your source is a QuickTime file rather than a WebM, note that X's own advice points the same way: for files that stall in processing, Media Studio's FAQ says "This happens most often with .mov files. If possible, re-export files as .mp4, which should allow for overall faster upload and processing time." The MOV to MP4 converter handles that case, and the full set is on the Clapr tools page.

Format is not the only thing that gets a file rejected

The API's media best-practices page lists hard constraints that have nothing to do with the container name, and any one of them can sink a file that is well under the size cap:

• Pixel aspect ratio: "must have 1:1"
• Pixel format: "Only YUV 4:2:0 is supported"
• Audio: "Audio must be AAC with Low Complexity profile. (High-Efficiency AAC is not supported)"
• Channels: "Audio must be mono or stereo, not 5.1 or greater"
• GOP: "Must not have open GOP"
• Scan type: "Must use progressive scan"

Re-exporting to H.264 in an MP4 container with AAC LC audio settles most of these in one pass, which is the practical argument for converting rather than experimenting.

X Ads makes the general point bluntly: "Even if your file is under our maximum size, we may still have issues ingesting the file." Its suggested remedy is to re-export at a lower bitrate — compress the video if a smaller file is what you need.

Platform-specific gotchas

• "Video too long" may not be about length. Media Studio's FAQ states: "Error: 'Video too long' — This error usually appears when uploading media that isn't in a supported format." If you hit that error on a short clip, treat it as a format signal. More on that in why X says your video is too long.
• Size caps differ by page, too. The help center says free accounts can upload "videos up to 140 seconds long with a maximum file size of 512MB", while the developer documentation lists 20 minutes and 8 GB for post video. Both are official. See X's video file size limit and the rest of the limits hub.
• Subtitles have the same scope split. text/vtt sits in that same API media_type enum, but the help center pages on captions only ever describe .srt. If you need a sidecar caption file for X, convert VTT to SRT rather than assuming VTT works.
• Codecs inside the container are undocumented. X's help and developer pages say nothing about HEVC, H.265, AV1 or VP9 anywhere. Claims you find asserting X does or does not support them have no official source behind them.

FAQ

Does X support WebM video uploads? X has never published a supported-format list for uploads from x.com or its mobile apps. video/webm is listed as an accepted value for the media_type parameter in the X API's initialize-upload schema, and Media Studio's separate list names only .MP4, .MOV. For anything beyond that, check the official documentation.

If video/webm is in the API schema, why do people say X rejects WebM? Because those are different scopes. The enum describes what one API request parameter accepts. The help center page for web uploads lists no formats and only says "You'll be prompted if the video isn't in a supported format", so there is no official page confirming the web composer behaves like the API.

Should I convert WebM to MP4 before posting to X? Yes, if you want the path with the most official backing. Media Studio specifies .MP4, .MOV, X Ads specifies "MP4 or MOV", and the API best-practices page recommends H.264 High Profile. MP4 is the only container all three agree on.

Does X accept VP9 or AV1 inside a WebM file? X's official documentation doesn't state this. The pages that discuss codecs recommend H.264 and set constraints on pixel format, audio profile, GOP and scan type, but they never name VP9 or AV1 either way.

My upload finished and then failed. Was it the format? Possibly. X documents that "Upload limits and Post-create limits are separately enforced", so a file can finalize and still be refused at post time. Format, pixel format, audio profile and size are all candidates — work through the constraint list above. Why X uploads fail covers the error paths in more detail.

Quotes above are taken from X's help center video and Media Studio pages, the X API v2 media documentation, and X's Ads creative specs, checked 16 September 2026. Where those pages disagree, both readings are shown rather than merged — verify the current values against the official documentation before relying on them.