Hi all,
I'd like to share a Toolforge tool I've built for uploading device-recorded videos to Wikimedia Commons: clip2commons.
https://clip2commons.toolforge.org/
It encodes locally in the browser using the WebCodecs API and uploads via the official MediaWiki API.
WHY ANOTHER TOOL
This is intended to complement, not replace, video2commons. video2commons handles URL imports (YouTube, archive.org, etc.) and remains the right tool for that workflow.
clip2commons covers a different case: a video file already on the user's device that needs to reach Commons. For that case, the existing options are:
- video2commons (file upload mode): the file goes to a Toolforge encoder pool that is shared and currently overstretched (Community Wishlist W447, W392, W443, W512, W523, W536 are open about v2c stability or capability gaps). - UploadWizard: accepts files up to 5 GB chunked, but does not convert formats. iPhone .mov and many Android .mp4 files fail TimedMediaHandler post-upload or upload as patent-encumbered formats. - Manual ffmpeg + UploadWizard: works for those who can do it, but is outside what most uploaders are willing or able to manage.
clip2commons does the WebM/VP9 conversion in the browser via WebCodecs, then uploads chunk-by-chunk to commons.wikimedia.org. There is no shared queue, no server-side encoder pool, and no infrastructure that needs maintenance to keep the tool running. The only resource constraint is the user's own device.
VALIDATION
End-to-end test, 1-2 Mbps connection, 683 MB 1080x1920 portrait (Original) file (6 min 13 s):
- In-browser encode: 15 min 20 s - Total wall-clock (encode + upload combined): ~16 minutes - Final file: 163 MB, VP9/Opus, 1080x1920 - Result on Commons:
https://commons.wikimedia.org/wiki/File:Wiki_Script_Publisher_Presentation_a...
PROVENANCE / LICENSING UI
The "Release rights" step mirrors UploadWizard's question tree exactly: same root choice (own work vs. someone else), same sub-questions for "contains the work of others" and "not protected by copyright law", same hard blocks for "I don't know" and "copyright-protected", same VRT-pending workflow for permission uploads, same set of accepted CC license templates per branch.
This was deliberate. Files uploaded through clip2commons should be indistinguishable in policy terms from files uploaded through UploadWizard or video2commons. The wikitext output uses the standard {{Information}} + {{self}} / bare-license-template structure with [[Category:Uploaded with clip2commons]].
BROWSER SUPPORT
Verified working (full encode + upload): - Google Chrome (desktop and mobile) - Microsoft Edge (desktop only) - Brave - DuckDuckGo browser - Samsung Internet - Dolphin - Bing browser - Opera Mini (already-WebM/VP9 files only)
Limited mode (already-WebM/VP9 files; cannot re-encode): - Firefox (desktop and mobile) - Safari (encoder support coming in 26.1)
Not currently supported: - Microsoft Edge on Android (WebCodecs implementation incompatible) - Opera (decoder errors at encode start) - Yandex - Tor Browser (WebCodecs disabled as fingerprinting protection)
Browsers in the "limited mode" or "not supported" lists show a clear banner up front instead of letting the user start a doomed upload. video2commons remains the recommended fallback for those browsers.
KNOWN LIMITS
- No URL imports. video2commons remains the right tool for that. - Hard cap: 1 GB / 1 hour input file. Larger files risk OOM during in-browser encode on memory-limited devices. - Encode time depends on the device. Modern hardware encodes at roughly 0.2x to 1x video duration; older devices can be slower.
FEEDBACK WELCOME
This is beta. Bug reports, policy / wikitext / copy review, and testing on devices and connections I do not have are all welcome.
- GitLab issues: https://gitlab.wikimedia.org/toolforge-repos/clip2commons (MIT) - My talk page: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya
Thanks, Dev Jadiya
Hey Dev
Excellent work. Hopefully we will be able to upload MP4s via the Upload Wizard soon. I think we are just waiting on legal.
James
On Sat, May 16, 2026 at 3:02 PM Dev Jadiya via Wikimedia-l wikimedia-l@lists.wikimedia.org wrote:
Hi all,
I'd like to share a Toolforge tool I've built for uploading device-recorded videos to Wikimedia Commons: clip2commons.
https://clip2commons.toolforge.org/
It encodes locally in the browser using the WebCodecs API and uploads via the official MediaWiki API.
WHY ANOTHER TOOL
This is intended to complement, not replace, video2commons. video2commons handles URL imports (YouTube, archive.org, etc.) and remains the right tool for that workflow.
clip2commons covers a different case: a video file already on the user's device that needs to reach Commons. For that case, the existing options are:
- video2commons (file upload mode): the file goes to a Toolforge encoder pool that is shared and currently overstretched (Community Wishlist W447, W392, W443, W512, W523, W536 are open about v2c stability or capability gaps).
- UploadWizard: accepts files up to 5 GB chunked, but does not convert formats. iPhone .mov and many Android .mp4 files fail TimedMediaHandler post-upload or upload as patent-encumbered formats.
- Manual ffmpeg + UploadWizard: works for those who can do it, but is outside what most uploaders are willing or able to manage.
clip2commons does the WebM/VP9 conversion in the browser via WebCodecs, then uploads chunk-by-chunk to commons.wikimedia.org. There is no shared queue, no server-side encoder pool, and no infrastructure that needs maintenance to keep the tool running. The only resource constraint is the user's own device.
VALIDATION
End-to-end test, 1-2 Mbps connection, 683 MB 1080x1920 portrait (Original) file (6 min 13 s):
- In-browser encode: 15 min 20 s
- Total wall-clock (encode + upload combined): ~16 minutes
- Final file: 163 MB, VP9/Opus, 1080x1920
- Result on Commons: https://commons.wikimedia.org/wiki/File:Wiki_Script_Publisher_Presentation_a...
PROVENANCE / LICENSING UI
The "Release rights" step mirrors UploadWizard's question tree exactly: same root choice (own work vs. someone else), same sub-questions for "contains the work of others" and "not protected by copyright law", same hard blocks for "I don't know" and "copyright-protected", same VRT-pending workflow for permission uploads, same set of accepted CC license templates per branch.
This was deliberate. Files uploaded through clip2commons should be indistinguishable in policy terms from files uploaded through UploadWizard or video2commons. The wikitext output uses the standard {{Information}} + {{self}} / bare-license-template structure with [[Category:Uploaded with clip2commons]].
BROWSER SUPPORT
Verified working (full encode + upload):
- Google Chrome (desktop and mobile)
- Microsoft Edge (desktop only)
- Brave
- DuckDuckGo browser
- Samsung Internet
- Dolphin
- Bing browser
- Opera Mini (already-WebM/VP9 files only)
Limited mode (already-WebM/VP9 files; cannot re-encode):
- Firefox (desktop and mobile)
- Safari (encoder support coming in 26.1)
Not currently supported:
- Microsoft Edge on Android (WebCodecs implementation incompatible)
- Opera (decoder errors at encode start)
- Yandex
- Tor Browser (WebCodecs disabled as fingerprinting protection)
Browsers in the "limited mode" or "not supported" lists show a clear banner up front instead of letting the user start a doomed upload. video2commons remains the recommended fallback for those browsers.
KNOWN LIMITS
- No URL imports. video2commons remains the right tool for that.
- Hard cap: 1 GB / 1 hour input file. Larger files risk OOM during in-browser encode on memory-limited devices.
- Encode time depends on the device. Modern hardware encodes at roughly 0.2x to 1x video duration; older devices can be slower.
FEEDBACK WELCOME
This is beta. Bug reports, policy / wikitext / copy review, and testing on devices and connections I do not have are all welcome.
- GitLab issues: https://gitlab.wikimedia.org/toolforge-repos/clip2commons (MIT)
- My talk page: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya
Thanks, Dev Jadiya _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Hi James,
Thanks for the kind words. Hopefully, legal resolves the MP4 situation soon.
Best, Dev Jadiya
On Sat, May 16, 2026 at 6:41 PM James Heilman jmh649@gmail.com wrote:
Hey Dev
Excellent work. Hopefully we will be able to upload MP4s via the Upload Wizard soon. I think we are just waiting on legal.
James
On Sat, May 16, 2026 at 3:02 PM Dev Jadiya via Wikimedia-l wikimedia-l@lists.wikimedia.org wrote:
Hi all,
I'd like to share a Toolforge tool I've built for uploading device-recorded videos to Wikimedia Commons: clip2commons.
https://clip2commons.toolforge.org/
It encodes locally in the browser using the WebCodecs API and uploads via the official MediaWiki API.
WHY ANOTHER TOOL
This is intended to complement, not replace, video2commons. video2commons handles URL imports (YouTube, archive.org, etc.) and remains the right tool for that workflow.
clip2commons covers a different case: a video file already on the user's device that needs to reach Commons. For that case, the existing options are:
- video2commons (file upload mode): the file goes to a Toolforge encoder pool that is shared and currently overstretched (Community Wishlist W447, W392, W443, W512, W523, W536 are open about v2c stability or capability gaps).
- UploadWizard: accepts files up to 5 GB chunked, but does not convert formats. iPhone .mov and many Android .mp4 files fail TimedMediaHandler post-upload or upload as patent-encumbered formats.
- Manual ffmpeg + UploadWizard: works for those who can do it, but is outside what most uploaders are willing or able to manage.
clip2commons does the WebM/VP9 conversion in the browser via WebCodecs, then uploads chunk-by-chunk to commons.wikimedia.org. There is no shared queue, no server-side encoder pool, and no infrastructure that needs maintenance to keep the tool running. The only resource constraint is the user's own device.
VALIDATION
End-to-end test, 1-2 Mbps connection, 683 MB 1080x1920 portrait (Original) file (6 min 13 s):
- In-browser encode: 15 min 20 s
- Total wall-clock (encode + upload combined): ~16 minutes
- Final file: 163 MB, VP9/Opus, 1080x1920
- Result on Commons:
https://commons.wikimedia.org/wiki/File:Wiki_Script_Publisher_Presentation_a...
PROVENANCE / LICENSING UI
The "Release rights" step mirrors UploadWizard's question tree exactly: same root choice (own work vs. someone else), same sub-questions for "contains the work of others" and "not protected by copyright law", same hard blocks for "I don't know" and "copyright-protected", same VRT-pending workflow for permission uploads, same set of accepted CC license templates per branch.
This was deliberate. Files uploaded through clip2commons should be indistinguishable in policy terms from files uploaded through UploadWizard or video2commons. The wikitext output uses the standard {{Information}} + {{self}} / bare-license-template structure with [[Category:Uploaded with clip2commons]].
BROWSER SUPPORT
Verified working (full encode + upload):
- Google Chrome (desktop and mobile)
- Microsoft Edge (desktop only)
- Brave
- DuckDuckGo browser
- Samsung Internet
- Dolphin
- Bing browser
- Opera Mini (already-WebM/VP9 files only)
Limited mode (already-WebM/VP9 files; cannot re-encode):
- Firefox (desktop and mobile)
- Safari (encoder support coming in 26.1)
Not currently supported:
- Microsoft Edge on Android (WebCodecs implementation incompatible)
- Opera (decoder errors at encode start)
- Yandex
- Tor Browser (WebCodecs disabled as fingerprinting protection)
Browsers in the "limited mode" or "not supported" lists show a clear banner up front instead of letting the user start a doomed upload. video2commons remains the recommended fallback for those browsers.
KNOWN LIMITS
- No URL imports. video2commons remains the right tool for that.
- Hard cap: 1 GB / 1 hour input file. Larger files risk OOM during in-browser encode on memory-limited devices.
- Encode time depends on the device. Modern hardware encodes at roughly 0.2x to 1x video duration; older devices can be slower.
FEEDBACK WELCOME
This is beta. Bug reports, policy / wikitext / copy review, and testing on devices and connections I do not have are all welcome.
- GitLab issues: https://gitlab.wikimedia.org/toolforge-repos/clip2commons (MIT)
- My talk page: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya
Thanks, Dev Jadiya _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines
at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/...
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian
This is really cool tool, Dev. Thank you for making this. Just uploaded a short video of a train arriving and the tool was faster than the train!
Subhashish
On Sat, 16 May, 2026, 6:53 pm Dev Jadiya via Wikimedia-l, < wikimedia-l@lists.wikimedia.org> wrote:
Hi James,
Thanks for the kind words. Hopefully, legal resolves the MP4 situation soon.
Best, Dev Jadiya
On Sat, May 16, 2026 at 6:41 PM James Heilman jmh649@gmail.com wrote:
Hey Dev
Excellent work. Hopefully we will be able to upload MP4s via the Upload Wizard soon. I think we are just waiting on legal.
James
On Sat, May 16, 2026 at 3:02 PM Dev Jadiya via Wikimedia-l wikimedia-l@lists.wikimedia.org wrote:
Hi all,
I'd like to share a Toolforge tool I've built for uploading device-recorded videos to Wikimedia Commons: clip2commons.
https://clip2commons.toolforge.org/
It encodes locally in the browser using the WebCodecs API and uploads via the official MediaWiki API.
WHY ANOTHER TOOL
This is intended to complement, not replace, video2commons. video2commons handles URL imports (YouTube, archive.org, etc.) and remains the right tool for that workflow.
clip2commons covers a different case: a video file already on the user's device that needs to reach Commons. For that case, the existing options are:
- video2commons (file upload mode): the file goes to a Toolforge encoder pool that is shared and currently overstretched (Community Wishlist W447, W392, W443, W512, W523, W536 are open about v2c stability or capability gaps).
- UploadWizard: accepts files up to 5 GB chunked, but does not convert formats. iPhone .mov and many Android .mp4 files fail TimedMediaHandler post-upload or upload as patent-encumbered formats.
- Manual ffmpeg + UploadWizard: works for those who can do it, but is outside what most uploaders are willing or able to manage.
clip2commons does the WebM/VP9 conversion in the browser via WebCodecs, then uploads chunk-by-chunk to commons.wikimedia.org. There is no shared queue, no server-side encoder pool, and no infrastructure that needs maintenance to keep the tool running. The only resource constraint is the user's own device.
VALIDATION
End-to-end test, 1-2 Mbps connection, 683 MB 1080x1920 portrait (Original) file (6 min 13 s):
- In-browser encode: 15 min 20 s
- Total wall-clock (encode + upload combined): ~16 minutes
- Final file: 163 MB, VP9/Opus, 1080x1920
- Result on Commons:
https://commons.wikimedia.org/wiki/File:Wiki_Script_Publisher_Presentation_a...
PROVENANCE / LICENSING UI
The "Release rights" step mirrors UploadWizard's question tree exactly: same root choice (own work vs. someone else), same sub-questions for "contains the work of others" and "not protected by copyright law", same hard blocks for "I don't know" and "copyright-protected", same VRT-pending workflow for permission uploads, same set of accepted CC license templates per branch.
This was deliberate. Files uploaded through clip2commons should be indistinguishable in policy terms from files uploaded through UploadWizard or video2commons. The wikitext output uses the standard {{Information}} + {{self}} / bare-license-template structure with [[Category:Uploaded with clip2commons]].
BROWSER SUPPORT
Verified working (full encode + upload):
- Google Chrome (desktop and mobile)
- Microsoft Edge (desktop only)
- Brave
- DuckDuckGo browser
- Samsung Internet
- Dolphin
- Bing browser
- Opera Mini (already-WebM/VP9 files only)
Limited mode (already-WebM/VP9 files; cannot re-encode):
- Firefox (desktop and mobile)
- Safari (encoder support coming in 26.1)
Not currently supported:
- Microsoft Edge on Android (WebCodecs implementation incompatible)
- Opera (decoder errors at encode start)
- Yandex
- Tor Browser (WebCodecs disabled as fingerprinting protection)
Browsers in the "limited mode" or "not supported" lists show a clear banner up front instead of letting the user start a doomed upload. video2commons remains the recommended fallback for those browsers.
KNOWN LIMITS
- No URL imports. video2commons remains the right tool for that.
- Hard cap: 1 GB / 1 hour input file. Larger files risk OOM during in-browser encode on memory-limited devices.
- Encode time depends on the device. Modern hardware encodes at roughly 0.2x to 1x video duration; older devices can be slower.
FEEDBACK WELCOME
This is beta. Bug reports, policy / wikitext / copy review, and testing on devices and connections I do not have are all welcome.
- GitLab issues: https://gitlab.wikimedia.org/toolforge-repos/clip2commons (MIT)
- My talk page: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya
Thanks, Dev Jadiya _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org,
guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/...
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Hello Dev,
Congratulations, the coolest tool ever found to upload videos to Commons. I hope this will positively influence the volume of video contributions on Wikimedia in the coming days.
I just uploaded a video of 50+ MB, and it was done in 2-3 mins. Really appreciate your work on this.
Thanks for making it.
Best, Sai
On Sat, 16 May 2026 at 19:04, Subhashish via Wikimedia-l < wikimedia-l@lists.wikimedia.org> wrote:
This is really cool tool, Dev. Thank you for making this. Just uploaded a short video of a train arriving and the tool was faster than the train!
Subhashish
On Sat, 16 May, 2026, 6:53 pm Dev Jadiya via Wikimedia-l, < wikimedia-l@lists.wikimedia.org> wrote:
Hi James,
Thanks for the kind words. Hopefully, legal resolves the MP4 situation soon.
Best, Dev Jadiya
On Sat, May 16, 2026 at 6:41 PM James Heilman jmh649@gmail.com wrote:
Hey Dev
Excellent work. Hopefully we will be able to upload MP4s via the Upload Wizard soon. I think we are just waiting on legal.
James
On Sat, May 16, 2026 at 3:02 PM Dev Jadiya via Wikimedia-l wikimedia-l@lists.wikimedia.org wrote:
Hi all,
I'd like to share a Toolforge tool I've built for uploading device-recorded videos to Wikimedia Commons: clip2commons.
https://clip2commons.toolforge.org/
It encodes locally in the browser using the WebCodecs API and uploads via the official MediaWiki API.
WHY ANOTHER TOOL
This is intended to complement, not replace, video2commons. video2commons handles URL imports (YouTube, archive.org, etc.) and remains the right tool for that workflow.
clip2commons covers a different case: a video file already on the user's device that needs to reach Commons. For that case, the existing options are:
- video2commons (file upload mode): the file goes to a Toolforge encoder pool that is shared and currently overstretched (Community Wishlist W447, W392, W443, W512, W523, W536 are open about v2c stability or capability gaps).
- UploadWizard: accepts files up to 5 GB chunked, but does not convert formats. iPhone .mov and many Android .mp4 files fail TimedMediaHandler post-upload or upload as patent-encumbered formats.
- Manual ffmpeg + UploadWizard: works for those who can do it, but is outside what most uploaders are willing or able to manage.
clip2commons does the WebM/VP9 conversion in the browser via WebCodecs, then uploads chunk-by-chunk to commons.wikimedia.org. There is no shared queue, no server-side encoder pool, and no infrastructure that needs maintenance to keep the tool running. The only resource constraint is the user's own device.
VALIDATION
End-to-end test, 1-2 Mbps connection, 683 MB 1080x1920 portrait (Original) file (6 min 13 s):
- In-browser encode: 15 min 20 s
- Total wall-clock (encode + upload combined): ~16 minutes
- Final file: 163 MB, VP9/Opus, 1080x1920
- Result on Commons:
https://commons.wikimedia.org/wiki/File:Wiki_Script_Publisher_Presentation_a...
PROVENANCE / LICENSING UI
The "Release rights" step mirrors UploadWizard's question tree exactly: same root choice (own work vs. someone else), same sub-questions for "contains the work of others" and "not protected by copyright law", same hard blocks for "I don't know" and "copyright-protected", same VRT-pending workflow for permission uploads, same set of accepted CC license templates per branch.
This was deliberate. Files uploaded through clip2commons should be indistinguishable in policy terms from files uploaded through UploadWizard or video2commons. The wikitext output uses the standard {{Information}} + {{self}} / bare-license-template structure with [[Category:Uploaded with clip2commons]].
BROWSER SUPPORT
Verified working (full encode + upload):
- Google Chrome (desktop and mobile)
- Microsoft Edge (desktop only)
- Brave
- DuckDuckGo browser
- Samsung Internet
- Dolphin
- Bing browser
- Opera Mini (already-WebM/VP9 files only)
Limited mode (already-WebM/VP9 files; cannot re-encode):
- Firefox (desktop and mobile)
- Safari (encoder support coming in 26.1)
Not currently supported:
- Microsoft Edge on Android (WebCodecs implementation incompatible)
- Opera (decoder errors at encode start)
- Yandex
- Tor Browser (WebCodecs disabled as fingerprinting protection)
Browsers in the "limited mode" or "not supported" lists show a clear banner up front instead of letting the user start a doomed upload. video2commons remains the recommended fallback for those browsers.
KNOWN LIMITS
- No URL imports. video2commons remains the right tool for that.
- Hard cap: 1 GB / 1 hour input file. Larger files risk OOM during in-browser encode on memory-limited devices.
- Encode time depends on the device. Modern hardware encodes at roughly 0.2x to 1x video duration; older devices can be slower.
FEEDBACK WELCOME
This is beta. Bug reports, policy / wikitext / copy review, and testing on devices and connections I do not have are all welcome.
- GitLab issues: https://gitlab.wikimedia.org/toolforge-repos/clip2commons (MIT)
- My talk page: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya
Thanks, Dev Jadiya _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org,
guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/...
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Hi Dev,
Thanks for working on the tool and making life easier for many contributors. Uploading video on Wikimedia Commons has always been a real pain for people. I just have uploaded a 250 MB original file smoothly without any issue using your tool. Will try with bigger files.
Regards, Bodhisattwa
On Sat, May 16, 2026, 9:31 PM Nethi Sai Kiran via Wikimedia-l < wikimedia-l@lists.wikimedia.org> wrote:
Hello Dev,
Congratulations, the coolest tool ever found to upload videos to Commons. I hope this will positively influence the volume of video contributions on Wikimedia in the coming days.
I just uploaded a video of 50+ MB, and it was done in 2-3 mins. Really appreciate your work on this.
Thanks for making it.
Best, Sai
On Sat, 16 May 2026 at 19:04, Subhashish via Wikimedia-l < wikimedia-l@lists.wikimedia.org> wrote:
This is really cool tool, Dev. Thank you for making this. Just uploaded a short video of a train arriving and the tool was faster than the train!
Subhashish
On Sat, 16 May, 2026, 6:53 pm Dev Jadiya via Wikimedia-l, < wikimedia-l@lists.wikimedia.org> wrote:
Hi James,
Thanks for the kind words. Hopefully, legal resolves the MP4 situation soon.
Best, Dev Jadiya
On Sat, May 16, 2026 at 6:41 PM James Heilman jmh649@gmail.com wrote:
Hey Dev
Excellent work. Hopefully we will be able to upload MP4s via the Upload Wizard soon. I think we are just waiting on legal.
James
On Sat, May 16, 2026 at 3:02 PM Dev Jadiya via Wikimedia-l wikimedia-l@lists.wikimedia.org wrote:
Hi all,
I'd like to share a Toolforge tool I've built for uploading device-recorded videos to Wikimedia Commons: clip2commons.
https://clip2commons.toolforge.org/
It encodes locally in the browser using the WebCodecs API and uploads via the official MediaWiki API.
WHY ANOTHER TOOL
This is intended to complement, not replace, video2commons. video2commons handles URL imports (YouTube, archive.org, etc.) and remains the right tool for that workflow.
clip2commons covers a different case: a video file already on the user's device that needs to reach Commons. For that case, the existing options are:
- video2commons (file upload mode): the file goes to a Toolforge encoder pool that is shared and currently overstretched (Community Wishlist W447, W392, W443, W512, W523, W536 are open about v2c stability or capability gaps).
- UploadWizard: accepts files up to 5 GB chunked, but does not convert formats. iPhone .mov and many Android .mp4 files fail TimedMediaHandler post-upload or upload as patent-encumbered formats.
- Manual ffmpeg + UploadWizard: works for those who can do it, but is outside what most uploaders are willing or able to manage.
clip2commons does the WebM/VP9 conversion in the browser via WebCodecs, then uploads chunk-by-chunk to commons.wikimedia.org. There is no shared queue, no server-side encoder pool, and no infrastructure that needs maintenance to keep the tool running. The only resource constraint is the user's own device.
VALIDATION
End-to-end test, 1-2 Mbps connection, 683 MB 1080x1920 portrait (Original) file (6 min 13 s):
- In-browser encode: 15 min 20 s
- Total wall-clock (encode + upload combined): ~16 minutes
- Final file: 163 MB, VP9/Opus, 1080x1920
- Result on Commons:
https://commons.wikimedia.org/wiki/File:Wiki_Script_Publisher_Presentation_a...
PROVENANCE / LICENSING UI
The "Release rights" step mirrors UploadWizard's question tree exactly: same root choice (own work vs. someone else), same sub-questions for "contains the work of others" and "not protected by copyright law", same hard blocks for "I don't know" and "copyright-protected", same VRT-pending workflow for permission uploads, same set of accepted CC license templates per branch.
This was deliberate. Files uploaded through clip2commons should be indistinguishable in policy terms from files uploaded through UploadWizard or video2commons. The wikitext output uses the standard {{Information}} + {{self}} / bare-license-template structure with [[Category:Uploaded with clip2commons]].
BROWSER SUPPORT
Verified working (full encode + upload):
- Google Chrome (desktop and mobile)
- Microsoft Edge (desktop only)
- Brave
- DuckDuckGo browser
- Samsung Internet
- Dolphin
- Bing browser
- Opera Mini (already-WebM/VP9 files only)
Limited mode (already-WebM/VP9 files; cannot re-encode):
- Firefox (desktop and mobile)
- Safari (encoder support coming in 26.1)
Not currently supported:
- Microsoft Edge on Android (WebCodecs implementation incompatible)
- Opera (decoder errors at encode start)
- Yandex
- Tor Browser (WebCodecs disabled as fingerprinting protection)
Browsers in the "limited mode" or "not supported" lists show a clear banner up front instead of letting the user start a doomed upload. video2commons remains the recommended fallback for those browsers.
KNOWN LIMITS
- No URL imports. video2commons remains the right tool for that.
- Hard cap: 1 GB / 1 hour input file. Larger files risk OOM during in-browser encode on memory-limited devices.
- Encode time depends on the device. Modern hardware encodes at roughly 0.2x to 1x video duration; older devices can be slower.
FEEDBACK WELCOME
This is beta. Bug reports, policy / wikitext / copy review, and testing on devices and connections I do not have are all welcome.
- GitLab issues: https://gitlab.wikimedia.org/toolforge-repos/clip2commons (MIT)
- My talk page: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya
Thanks, Dev Jadiya _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org,
guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/...
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
-- James Heilman MD, CCFP-EM, Wikipedian
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Helo Dev and ClipToCommons Development Team,
I would like to thank you for developing the ClipToCommons tool. I recently used it to upload a couple of videos to Wikimedia Commons, and I found it to be a very interesting and user-friendly tool. The workflow is simple, and it makes uploading video clips much easier compared to other methods.
While using the tool, I noticed a few issues and have some suggestions that may help improve the user experience:
1.
*Metadata Fetching:* The tool couldn't automatically fetch metadata for some videos (e.g., date). 2.
*Licence*: Although there is an option to specify the license during upload, the license is not displayed on the uploaded file page, resulting in a Wikimedia Commons speedy deletion warning. 3.
*Description Editing:* It would be great if the description field could integrate with the Content Translation tool or provide multilingual editing support. This would make it much easier for contributors to prepare descriptions in multiple languages before uploading. 4.
*Custom Thumbnail Selection:* It would be a valuable addition if users could select a custom thumbnail (or choose a frame from the video) before uploading. This would allow contributors to highlight the most representative or visually appealing frame, making the uploaded videos more informative and attractive on Wikimedia Commons.
Overall, I really enjoyed using ClipToCommons and appreciate the effort that has gone into developing this tool. I hope these suggestions are helpful and contribute to making it even better for the Wikimedia community.
Thank you for your hard work and continued support of Wikimedia contributors.
Best,
Bharathesha Alasandemajalu
On Sat, 16 May 2026 at 18:32, Dev Jadiya via Wikimedia-l < wikimedia-l@lists.wikimedia.org> wrote:
Hi all,
I'd like to share a Toolforge tool I've built for uploading device-recorded videos to Wikimedia Commons: clip2commons.
https://clip2commons.toolforge.org/
It encodes locally in the browser using the WebCodecs API and uploads via the official MediaWiki API.
WHY ANOTHER TOOL
This is intended to complement, not replace, video2commons. video2commons handles URL imports (YouTube, archive.org, etc.) and remains the right tool for that workflow.
clip2commons covers a different case: a video file already on the user's device that needs to reach Commons. For that case, the existing options are:
- video2commons (file upload mode): the file goes to a Toolforge encoder pool that is shared and currently overstretched (Community Wishlist W447, W392, W443, W512, W523, W536 are open about v2c stability or capability gaps).
- UploadWizard: accepts files up to 5 GB chunked, but does not convert formats. iPhone .mov and many Android .mp4 files fail TimedMediaHandler post-upload or upload as patent-encumbered formats.
- Manual ffmpeg + UploadWizard: works for those who can do it, but is outside what most uploaders are willing or able to manage.
clip2commons does the WebM/VP9 conversion in the browser via WebCodecs, then uploads chunk-by-chunk to commons.wikimedia.org. There is no shared queue, no server-side encoder pool, and no infrastructure that needs maintenance to keep the tool running. The only resource constraint is the user's own device.
VALIDATION
End-to-end test, 1-2 Mbps connection, 683 MB 1080x1920 portrait (Original) file (6 min 13 s):
- In-browser encode: 15 min 20 s
- Total wall-clock (encode + upload combined): ~16 minutes
- Final file: 163 MB, VP9/Opus, 1080x1920
- Result on Commons:
https://commons.wikimedia.org/wiki/File:Wiki_Script_Publisher_Presentation_a...
PROVENANCE / LICENSING UI
The "Release rights" step mirrors UploadWizard's question tree exactly: same root choice (own work vs. someone else), same sub-questions for "contains the work of others" and "not protected by copyright law", same hard blocks for "I don't know" and "copyright-protected", same VRT-pending workflow for permission uploads, same set of accepted CC license templates per branch.
This was deliberate. Files uploaded through clip2commons should be indistinguishable in policy terms from files uploaded through UploadWizard or video2commons. The wikitext output uses the standard {{Information}} + {{self}} / bare-license-template structure with [[Category:Uploaded with clip2commons]].
BROWSER SUPPORT
Verified working (full encode + upload):
- Google Chrome (desktop and mobile)
- Microsoft Edge (desktop only)
- Brave
- DuckDuckGo browser
- Samsung Internet
- Dolphin
- Bing browser
- Opera Mini (already-WebM/VP9 files only)
Limited mode (already-WebM/VP9 files; cannot re-encode):
- Firefox (desktop and mobile)
- Safari (encoder support coming in 26.1)
Not currently supported:
- Microsoft Edge on Android (WebCodecs implementation incompatible)
- Opera (decoder errors at encode start)
- Yandex
- Tor Browser (WebCodecs disabled as fingerprinting protection)
Browsers in the "limited mode" or "not supported" lists show a clear banner up front instead of letting the user start a doomed upload. video2commons remains the recommended fallback for those browsers.
KNOWN LIMITS
- No URL imports. video2commons remains the right tool for that.
- Hard cap: 1 GB / 1 hour input file. Larger files risk OOM during in-browser encode on memory-limited devices.
- Encode time depends on the device. Modern hardware encodes at roughly 0.2x to 1x video duration; older devices can be slower.
FEEDBACK WELCOME
This is beta. Bug reports, policy / wikitext / copy review, and testing on devices and connections I do not have are all welcome.
- GitLab issues: https://gitlab.wikimedia.org/toolforge-repos/clip2commons (MIT)
- My talk page: https://meta.wikimedia.org/wiki/User_talk:Dev_Jadiya
Thanks, Dev Jadiya _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Den sön 28 juni 2026 kl 09:34 skrev Bharathesha A B via Wikimedia-l < wikimedia-l@lists.wikimedia.org>:
*Custom Thumbnail Selection:* It would be a valuable addition if users could select a custom thumbnail (or choose a frame from the video) before uploading. This would allow contributors to highlight the most representative or visually appealing frame, making the uploaded videos more informative and attractive on Wikimedia Commons.
This is a good idea, but it is currently not possible to set a certain
frame as thumbnail for a video on Wikimedia Commons, see https://phabricator.wikimedia.org/T22647
/Jan
👍
Bharathesha reacted via Gmail https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app
On Mon, 29 Jun, 2026, 5:57 pm Jan Ainali, ainali.jan@gmail.com wrote:
Den sön 28 juni 2026 kl 09:34 skrev Bharathesha A B via Wikimedia-l < wikimedia-l@lists.wikimedia.org>:
*Custom Thumbnail Selection:* It would be a valuable addition if users could select a custom thumbnail (or choose a frame from the video) before uploading. This would allow contributors to highlight the most representative or visually appealing frame, making the uploaded videos more informative and attractive on Wikimedia Commons.
This is a good idea, but it is currently not possible to set a certain
frame as thumbnail for a video on Wikimedia Commons, see https://phabricator.wikimedia.org/T22647
/Jan
wikimedia-l@lists.wikimedia.org