2026-09-04
Wikipedia won’t take your MP4 in 2026: Wikimedia Commons is WebM-only, and how to convert your footage without uploading it anywhere
Wikipedia does not host its own media. The photograph at the top of an article, the diagram halfway down, the short clip of a machine actually running — nearly all of it lives on Wikimedia Commons and is embedded into the article from there. So the moment you decide to contribute video — a heritage site, a piece of working machinery, a bird, a chemistry demo, a tram pulling into a station whose article has no clip at all — you meet a rule that catches almost everyone on the first attempt: Commons will not accept the MP4 your phone just made. Not "prefers something else". The file type is not on the accepted list, and the reason is licensing, not quality. Here are Commons' actual rules from Commons' own pages, the second gate nobody mentions until an upload dies at 100MB, and how to do the conversion on your own machine — including an honest account of when this tool is the wrong one for the job.
The rule, from Commons' own pages
Commons:File types is blunt: "Videos must be WebM files (.webm extension), Ogg files using the Theora video coding format (with a .ogv extension), or MPEG-1/MPEG-2 files (.mpg and .mpeg extension)." Commons:Video narrows that to a recommendation — "The preferred video format is WebM (.webm), which can contain video data encoded with the AV1, VP9 or VP8 codecs and audio encoded with Opus or Vorbis" — and adds the requirement people forget until an upload is refused over its soundtrack: "The audio data in a video file must also be in a free format, such as Vorbis or Opus." The same page says plainly why your camera's file is out: "Commons does not support the more commonly used patent-encumbered video formats such as H.264 (AVC) and H.265 (HEVC) that are used in MP4 and MOV files, since their use could require royalty payments." That is a licensing position, not a judgement about your footage — and it will not be waived because the clip is good.
One of the three accepted formats is effectively dead, which matters when you pick a target. Commons:Video says so itself: Ogg Theora and MPEG-1/2 "are also allowed on Commons, but they are not as widely supported in modern browsers", and it names the reason — "Chrome and Firefox recently removed support for Theora video decoding due to low adoption and cybersecurity concerns." Chromium's own Intent to Ship: Deprecate and remove Theora support dates it: remove the code in M123 around February 2024, with "Chrome 123 will roll to stable" the month after. So a .ogv uploaded today is a file most readers' browsers cannot play. In practice the accepted list has one live entry, and it is WebM.
The second gate: 100MB per upload
Format is the gate people hit first; size is the one they hit at minute nine of a fifteen-minute clip. Commons:Maximum file size puts it plainly: "the maximum file size for uploading is 100MB" through the ordinary form, while the ceiling for a file that is hosted sits far higher — Commons:Video says "Files can't be larger than 5GiB." The bridge between those two numbers is chunked uploading: "The UploadWizard and several community-supported tools can use chunked uploading to upload such files in smaller (<100MB) pieces that are reassembled on the server." A large file is not impossible, then; it just cannot go through the plain form.
What that means for the conversion you are about to run is arithmetic — mine, not Commons'. 100MB is 800 megabits, so at a 2 Mbit/s video bitrate plus an audio track of roughly 128 kbit/s you get about six minutes before the plain form turns you away; at 1 Mbit/s, about twelve. Encyclopedic video is usually short anyway — the process, the mechanism, the call, the approach — so most contributions never come near either number. If yours does, the honest options are to cut it shorter, encode it lower, or use UploadWizard.
Converting on your own machine, in one pass
NearVid's Convert to WebM runs a real FFmpeg build compiled to WebAssembly inside the page, so the file is read by your own browser and nothing is sent anywhere. The output is VP8 video with Vorbis audio, both of which sit on the accepted list above. This is the exact reverse of the usual WebM problem: most of the time WebM is the format you have to escape, and Commons is the rare destination that will take nothing else — the same conversion, pointed the other way.
Two practical details. First, the WebM card takes the same start and end fields as the trim card, so the cut and the conversion happen in one pass: you re-encode only the seconds you are keeping, which is faster and smaller than converting the whole capture and trimming afterwards. Second, because an encoder is running either way, this cut lands exactly where you typed it — unlike the lossless stream copy in the trim card, which can only start on a keyframe. The quality picker is three fixed bitrates (High 2 Mbit/s, Medium 1 Mbit/s, Low 500 kbit/s), and the "≈" figure beside it is a labeled estimate computed as bitrate × duration, not a measurement: read it to choose, then check the finished file's real size against the 100MB gate.
When this is the wrong tool — Commons' own guide says so
Read this section before converting anything long. Commons' Help:Converting video recommends VP9 video with Opus audio, encoded two-pass at a constant quality level, where "the target quality of -crf is specified on a scale from 0 to 63, with smaller values indicating higher quality" and 30 is the default for HD. NearVid does not do that. It writes VP8 and Vorbis at a fixed bitrate in a single pass, and that is a deliberate choice rather than an oversight: the VP9 path hit a reproducible crash in this build's own logging callback during the engineering spike, so the tool ships the codec pair it verified end to end. VP8 and Vorbis are explicitly on Commons' allowed list, so the upload will be accepted — but VP9 and AV1 deliver noticeably more quality per megabyte, and when the material is long, detailed, or close to the 100MB gate, that difference is the whole game. For those uploads, follow Commons' own guide: desktop FFmpeg, or the video2commons tool it names. Local conversion is a privacy property, not a quality claim.
The rest of the honesty list is short. NearVid processes the whole file in memory, so it accepts up to 500MB per file on a desktop and 50MB on phones and low-memory devices — and a multi-minute 4K capture will often exceed that phone number on the very phone that shot it, in which case move the file to a computer. It does not resize: a 4K source becomes a 4K WebM, which is usually what Commons wants and also what makes the file heavy. There is no stabilization, no merging of several takes, no subtitle track, and no "fit under 100MB" button — only the labeled estimate and the real size afterwards. And one thing no tool can fix: your camera's MP4 is already a lossy encode, so any WebM is a second generation. There is no lossless path from H.264 to a free format, so the rule is simply to convert once, from the original camera file, rather than from a copy that has already been through a messaging app.
The parts the file format does not cover
Passing the format check is the easy half. Commons is a free-content project, so Commons:Licensing requires the file itself to be freely licensed — normally because you shot it and you release it — and footage you merely found, or a clip with someone else's music running under it, does not qualify however it is encoded. People add a second layer: Commons' guideline on photographs of identifiable people says "publishing a photo of an identifiable person in a private place usually requires consent, and Commons expects this even if relevant laws do not require it", while "in many countries (especially English-speaking ones), publishing a straightforward photo of an identifiable person in a public place usually does not require consent" — with country-by-country variation the page is explicit about. Both are reasons to convert locally: shoot, convert, watch the result, and then decide not to publish is a perfectly normal sequence, and it only stays private if the conversion step never involved a stranger's server.
Stills from the same footage
Photographs are welcome on Commons in the ordinary formats — Commons:File types names JPEG as "appropriate for photographs, especially when the photographs are already JPEGs" and PNG for drawings and diagrams — and a frame from footage you shot is your own work exactly as the footage is. NearVid's frame extraction pulls the frame at the timestamp you type, as a JPG or PNG at the capture's own resolution, without re-encoding the video; the still-frame post covers how to choose one worth uploading. One thing to be precise about: Wiki Loves Monuments, whose 2026 edition runs in a 30- or 31-day window inside September and October with an October 31 final deadline, describes itself as "an annual photo contest", and whether a video still counts as an entry is the organisers' call, not this article's. Outside a contest, the question does not arise.
The honest summary
From Commons' own pages: video must be .webm, .ogv, or .mpg/.mpeg; MP4 and MOV are out because H.264 and H.265 "could require royalty payments"; the audio has to be free too, Vorbis or Opus; the plain upload form stops at 100MB, with 5 GiB reachable through UploadWizard's chunked upload; and of the three accepted formats only WebM still plays in current browsers, since Chrome removed Theora decoding in version 123. NearVid converts to WebM (VP8 + Vorbis) entirely inside your browser, cutting and encoding in one pass, with no upload at any point — the right shape for footage you have not yet committed to publishing. If the clip is long or the 100MB gate is tight, Commons' own conversion guide and its VP9 + Opus recipe will serve the encyclopedia better than this tool will, and saying so is part of the job.