Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
* What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
* What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
* Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
* What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
* What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps - https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Hi Amir,
Thanks for the heads up on this. I'm confused about the idea of standard "sizes", as listed. Thumbnails have two dimensions, two sizes, width and height right? Do both dimensions have to be one of the standard sizes? What if that causes image stretching?
Thanks, -Travis
On Fri, Jan 23, 2026 at 10:28 AM Amir Sarabadani via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikimedia thumbnail URLs are based on width only. Scaling maintains the original ratio.
AntiCompositeNumber (they/them)
On Fri, Jan 23, 2026, at 13:41, Travis Briggs wrote:
Hi Amir,
Thanks for the heads up on this. I'm confused about the idea of standard "sizes", as listed. Thumbnails have two dimensions, two sizes, width and height right? Do both dimensions have to be one of the standard sizes? What if that causes image stretching?
Thanks, -Travis
On Fri, Jan 23, 2026 at 10:28 AM Amir Sarabadani via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps - https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Oh right, thanks, I think I knew that at one point...
So if I have the following response from the mobile API, with a "lazy load" image:
<span class="mw-file-element gallery-img pcs-widen-image-override pcs-lazy-load-placeholder pcs-lazy-load-placeholder-pending" style="width: 1500px" data-class="mw-file-element gallery-img pcs-widen-image-override" data-src="// upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/1200px-BMW.svg.png " data-width="1200" data-height="1500" data-alt="Logo used in vehicles since 1997" data-data-file-width="2400" data-data-file-height="3000" data-data-file-original-src="// upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/800px-BMW.svg.png" ><span style="padding-top: 100%">
And I want to convert it to an actual <img> tag at a smaller size, also embedding the image binary in our app (Kiwix), I should no longer request https://upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/*400px* -BMW.svg.png (and then set the width/height attributes to 400px by 320px in the app), but instead request https://upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/*330**px* -BMW.svg.png and set the height to 264px?
Thanks, -Travis
On Fri, Jan 23, 2026 at 10:43 AM AntiCompositeNumber acn@anticomposite.net wrote:
Wikimedia thumbnail URLs are based on width only. Scaling maintains the original ratio.
AntiCompositeNumber (they/them)
On Fri, Jan 23, 2026, at 13:41, Travis Briggs wrote:
Hi Amir,
Thanks for the heads up on this. I'm confused about the idea of standard "sizes", as listed. Thumbnails have two dimensions, two sizes, width and height right? Do both dimensions have to be one of the standard sizes? What if that causes image stretching?
Thanks, -Travis
On Fri, Jan 23, 2026 at 10:28 AM Amir Sarabadani via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
Thumbnails shown on-wiki are already quantized to a set of standard
sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via
the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g.
constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing
rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was
requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more
widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px,
1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see
https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
On Fri, Jan 23, 2026 at 1:56 PM Travis Briggs audiodude@gmail.com wrote:
So if I have the following response from the mobile API, with a "lazy load" image:
<span class="mw-file-element gallery-img pcs-widen-image-override pcs-lazy-load-placeholder pcs-lazy-load-placeholder-pending" style="width: 1500px" data-class="mw-file-element gallery-img pcs-widen-image-override" data-src="// upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/1200px-BMW.svg.png " data-width="1200" data-height="1500" data-alt="Logo used in vehicles since 1997" data-data-file-width="2400" data-data-file-height="3000" data-data-file-original-src="// upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/800px-BMW.svg.png " ><span style="padding-top: 100%">
And I want to convert it to an actual <img> tag at a smaller size, also embedding the image binary in our app (Kiwix), I should no longer request https://upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/*400px* -BMW.svg.png (and then set the width/height attributes to 400px by 320px in the app), but instead request https://upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/*330* *px*-BMW.svg.png and set the height to 264px?
While poking at Popups and other bits I added a helper function to mw.util to replicate the steps logic from the PHP side as a helper for JS logic that does this sort of thing. Something like this should work for this use case:
let url = '// upload.wikimedia.org/wikipedia/commons/thumb/4/44/BMW.svg/1200px-BMW.svg.png '; let target = 400; // not necessarily a standard size let info = mw.util.parseImageUrl( url ); if ( info && info.resizeUrl ) { // this should force the target to a standard size target = mw.util.adjustThumbWidthForSteps( target, info.width ); // and this will rewrite the URL url = info.resizeUrl( target ); }
Probably we should encapsulate this whole bit into an easier to use single function. :)
-- brooke
On Fri, 2026-01-23 at 10:41 -0800, Travis Briggs wrote:
Thanks for the heads up on this. I'm confused about the idea of standard "sizes", as listed. Thumbnails have two dimensions, two sizes, width and height right? Do both dimensions have to be one of the standard sizes? What if that causes image stretching?
Per https://www.mediawiki.org/wiki/Common_thumbnail_sizes , "Unless otherwise noted, the sizes mean width in pixels."
Cheers, andre
Are we going to change $wgImageLimits to match, because as it stands, it is pretty weird to have default sizes we don't serve.
-- Brian
On Fri, Jan 23, 2026 at 10:28 AM Amir Sarabadani via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
This is great, and I'm sure many 3rd party installs will be glad of it too (to reduce their thumb storage requirements).
A couple of times lately I've had the "429 Use thumbnail steps listed on https://w.wiki/GHai" message, and because I'm a bit slow on the uptake I went looking for the steps to follow to get thumbnails. Has anyone else been confused by this? If it's just me, ignore this, but perhaps we could update the message to say "Use the values of $wgThumbnailSteps listed on…" instead.
On 24/1/26 02:27, Amir Sarabadani via Wikitech-l wrote:
Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org http://upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps - https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Wikitech-l mailing list --wikitech-l@lists.wikimedia.org To unsubscribe send an email towikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Added an "FAQ" section to that article. How does it look now? https://www.mediawiki.org/wiki/Common_thumbnail_sizes
Cheers, -Travis
On Fri, Jan 23, 2026 at 10:38 PM Sam Wilson via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
This is great, and I'm sure many 3rd party installs will be glad of it too (to reduce their thumb storage requirements).
A couple of times lately I've had the "429 Use thumbnail steps listed on https://w.wiki/GHai" message, and because I'm a bit slow on the uptake I went looking for the steps to follow to get thumbnails. Has anyone else been confused by this? If it's just me, ignore this, but perhaps we could update the message to say "Use the values of $wgThumbnailSteps listed on…" instead.
On 24/1/26 02:27, Amir Sarabadani via Wikitech-l wrote:
Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.orghttps://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Looks great, thanks!
On 25/1/26 12:32, Travis Briggs wrote:
Added an "FAQ" section to that article. How does it look now? https://www.mediawiki.org/wiki/Common_thumbnail_sizes
Cheers, -Travis
On Fri, Jan 23, 2026 at 10:38 PM Sam Wilson via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
This is great, and I'm sure many 3rd party installs will be glad of it too (to reduce their thumb storage requirements). A couple of times lately I've had the "429 Use thumbnail steps listed on https://w.wiki/GHai" message, and because I'm a bit slow on the uptake I went looking for the steps to follow to get thumbnails. Has anyone else been confused by this? If it's just me, ignore this, but perhaps we could update the message to say "Use the values of $wgThumbnailSteps listed on…" instead. On 24/1/26 02:27, Amir Sarabadani via Wikitech-l wrote:Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all. * What isn't changing? Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate. * What is changing? Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org <http://upload.wikimedia.org> URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser. During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026. * Why are WMF doing this? Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse. * What do I need to do? Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes. * What are the standard thumbnail sizes? They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px They are defined in config as $wgThumbnailSteps - https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/CommonSettings.php And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them. Best -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation <https://wikimediafoundation.org/> _______________________________________________ Wikitech-l mailing list --wikitech-l@lists.wikimedia.org To unsubscribe send an email towikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/_______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Hello, An update regarding this change. Now the ratio of requests to standard thumbnail sizes has reached 99.75%, we have started to block any request to non-standard ones. For now, the block will be for a couple of hours every day during business hours so we can respond if any major issues are reported but in a week or two, we will make this permanent (granted if there are no major issues).
Please let us know if you have any issues or concerns regarding this change.
Best
Am Fr., 23. Jan. 2026 um 19:27 Uhr schrieb Amir Sarabadani < asarabadani@wikimedia.org>:
Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Pages on Wikipedia still seem to generate links to non-standard thumbsizes if you ask for a large thumb (e.g. [[File:Example.svg|1930px]] the 2x srcset is invalid. It should be setting the 2x to the original file or omitting it if 2x is too big. Instead it is linking to 3860px which doesn't work).
I know that is unusual, but I had a template that did some CSS hacks with a large image that really contained multiple sub-images, which just broke.
-- Brian
On Mon, Apr 20, 2026 at 5:56 AM Amir Sarabadani via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote:
Hello, An update regarding this change. Now the ratio of requests to standard thumbnail sizes has reached 99.75%, we have started to block any request to non-standard ones. For now, the block will be for a couple of hours every day during business hours so we can respond if any major issues are reported but in a week or two, we will make this permanent (granted if there are no major issues).
Please let us know if you have any issues or concerns regarding this change.
Best
Am Fr., 23. Jan. 2026 um 19:27 Uhr schrieb Amir Sarabadani < asarabadani@wikimedia.org>:
Thumbnails shown on-wiki are already quantized to a set of standard sizes (if a non-standard size is requested, the next-larger standard size is used, and scaled to the requested size by the browser). We have recently extended the set of standard sizes, and are now moving to only allow standard sizes to be used. Regular editing and viewing will not be impacted by this change at all.
- What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the Media API) will continue to behave as they do now - if you request a non-standard size, the next-larger standard size will be provided, and scaled in-browser if appropriate.
- What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g. constructing an upload.wikimedia.org URL with a non-standard thumbnail size) will be blocked by our CDN. These are already being rate-limited for requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing rate-limiting and making it increasingly strict, with the aim being to refuse such requests entirely by the end of March 2026.
- Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested; this has been a drain on our thumbnailing infrastructure and cost us in network bandwidth and storage volume. With the increasing prevalence of highly aggressive scrapers, this has become an intolerable burden on our network, infrastructure, and staff, who have spent a lot of time over the holiday period working hard to keep the wikis available for people to read in the face of automated abuse.
- What do I need to do?
Most likely, nothing: we have already tracked down some of the more widely-deployed sources of nonstandard thumbnail requests (e.g. Popups extension) and fixed them. If you own or operate something that requests thumbnails by constructing a thumbnail URI directly, then now is the time to either use the Media API instead or to make sure you only request standard thumbnail sizes.
- What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+...
And also documented on MetaWiki - https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see https://phabricator.wikimedia.org/T414805 for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation https://wikimediafoundation.org/
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
wikitech-l@lists.wikimedia.org