Most people who try to share a video on Wikimedia Commons run into the same wall. The phone records MP4. Commons accepts free formats such as WebM. Between the two sits a conversion step that assumes you know what a codec is, have a command-line tool installed, or are willing to wait in a shared server queue.
The contribution itself is usually simple: a festival procession, a craftsperson at work, a river after the monsoon, a public lecture. The steps around it are not. Clip2Commons is my attempt to close that gap.
Live tool: clip2commons.toolforge.org
Source code: GitLab
Issue tracker: Phabricator
Documentation: Wikitech
The problem is the workflow, not the encoder
Video conversion is a solved problem for anyone comfortable with a terminal. That is exactly why it is easy to overlook how much it filters out everyone else.
When I looked at how people actually contribute video to Commons, I saw three routes. You can convert the file yourself and upload it through the Upload Wizard. You can use video2commons, which does the conversion on a server and is excellent for imports from URLs. Or you can give up, which, judging by how few everyday videos Commons has compared with photographs, is what many people do.
The server route has a structural limit. Every conversion shares the same infrastructure, so heavy use or maintenance means waiting. And someone with a file already on their own device may not want to send it through a separate service before it reaches Commons.
So I set a narrow goal: if a person already has a video on their phone or laptop, they should be able to get it onto Commons, properly described, without installing anything.
Encode on your device, upload to Commons
Clip2Commons does the conversion inside the contributor's own browser. You pick a file, the tool inspects it, converts it to WebM with VP9 video and Opus audio where conversion is needed, and then uploads the result to Commons through the MediaWiki API under your own account.
Nothing goes to a Clip2Commons server for encoding. That has two consequences I care about. Uploads do not depend on a shared queue, and the original file stays on the contributor's device; only the converted file goes to Commons.
If a file is already WebM with VP8 or VP9 video, the tool passes it straight through without re-encoding. That saves time, battery and quality.
How it is built
The stack is deliberately close to what other Wikimedia tools use, so that it looks familiar and others can contribute:
Vue 3, TypeScript and Vite for the application.
Wikimedia Codex, the design system used across Wikimedia interfaces, so buttons, forms and messages behave the way Wikimedians expect.
WebCodecs and mediabunny for decoding, encoding and handling media containers in the browser.
A Web Worker for the encoding itself. Video encoding is heavy, and running it on the main thread would freeze the page. The worker reports progress back to the interface.
Chunked uploads through the MediaWiki API. Large files go up in parts, which is far more forgiving on a mobile connection.
OAuth 2.0 with the contributor's Wikimedia account, so every file is attributed to the person who uploaded it.
A Vitest unit test suite for title handling, wikitext and licence generation, API wrappers, chunked uploads, OAuth logic, browser capability detection, resumable-upload storage and translation bundles.
Hosting on Toolforge, Wikimedia's community platform for tools.
I am careful about what the tests prove. They cover reusable logic well. They do not prove that every browser on every device can encode every file, and the documentation says so.
Metadata is half the upload
The encoder is the interesting part technically, but most of the user experience lives in the metadata form. A video on Commons is only as useful as its title, description, licence, author and categories.
A few decisions mattered more than I expected:
The date can be pre-filled from the file, but never overwrites a value the contributor has already typed. A convenience that silently changes someone's input is a bug, not a feature.
Licences are chosen explicitly, and the tool can remember the last preset licence across uploads without turning it into an unsafe default.
Category autocomplete uses Commons itself, so people pick categories that exist rather than inventing near-duplicates.
Descriptions can be written in 244 languages, listed Indic-first, and are written as properly stacked
{{lang}}blocks inside the standard Information template. The editor can also suggest translations through MinT, Wikimedia's own machine-translation service, so a contributor can describe a video in Hindi and add an English line without leaving the form.
The interface is available in English, Hindi, Arabic (with right-to-left layout), French, Spanish, German, Chinese and Portuguese, and includes keyboard navigation, accessible progress messages and a skip-to-content link.
Going public
On 16 May 2026 I announced Clip2Commons as a public beta on the wikimedia-l mailing list. I tried to write the announcement the way I would want to read one: what problem it solves, how it differs from video2commons, what it does not support, and where to report problems.
The replies were encouraging and, more usefully, specific. Several later changes came directly from that thread. The tool was also featured in the South Asia Newsletter.
Every file uploaded through the tool lands in a hidden maintenance category, Uploaded with clip2commons. That lets anyone count real usage without any tracking on my side. At the time of writing, 187 videos have gone to Commons through it.
Letting other people into the code
A tool that only its author understands is fragile. In June 2026 I took Clip2Commons to the Indic Wikimedia Hackathon in Hyderabad as a mentoring project. Four contributors worked on it with me.
Preparation mattered more than the event. Before anyone arrived, I ran an onboarding call and prepared a walkthrough of roughly thirty slides on the architecture and the tasks. Over three days, eight merge requests were reviewed and merged: interface polish, date pre-fill from media metadata, an audio on/off toggle in the editor, complete Hindi translations, independently editable items in the batch queue, author override, a better recent-uploads panel, and accessibility fixes for the upload form.
Reviewing those changes taught me as much as writing my own. A batch queue looks simple until you check that each file keeps its own metadata when you switch between them. An audio toggle is only correct if the output file actually has no audio.
Later work expanded translations, remembered licence presets, and dealt with iOS and WebKit memory pressure, where Safari could quietly reset the form on long videos.
Honest limits
Encoding video in a browser uses real memory and processing power. A long 4K file that works on a desktop may fail on an older phone. WebCodecs support still differs between browsers. The tool does not import from URLs; video2commons remains the right choice for that.
I would rather say these things clearly than let people discover them halfway through an upload. Accurate status messages are part of correctness: a tool should never imply an upload succeeded when it did not.
In October 2026 I also decided to stop adding features. Clip2Commons should do one job reliably. New ideas will become separate tools.
Why this matters to me
Commons holds millions of photographs and comparatively few videos of everyday culture, crafts, rituals, food and landscapes, especially from smaller communities. Many of those videos already exist on people's phones. If a file format is the only thing standing between them and a free archive, that is a problem worth solving.
The longer project record, including design decisions and what I would do differently, is in my Clip2Commons logbook on Meta-Wiki.