Standardisation of thumbnail sizes - Wikitech-l - lists.wikimedia.org

Standardisation of thumbnail sizes - Wikitech-l - lists.wikimedia.org
Keyboard Shortcuts
Thread View
: Next unread message
: Previous unread message
j a
: Jump to all threads
j l
: Jump to MailingList overview
List overview
All Threads
newer
Standardisation of thumbnail sizes
older
🚀 Launched: Attribution API (Beta)...
Tech News 2026 - Issue 17
First Post
Replies
Stats
Threads by
month
----- 2026 -----
April
March
February
January
----- 2025 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2024 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2023 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2022 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2021 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2020 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2019 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2018 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2017 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2016 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2015 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2014 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2013 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2012 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2011 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2010 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2009 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2008 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2007 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2006 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2005 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2004 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2003 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2002 -----
December
November
October
September
August
July
June
May
April
March
February
Amir Sarabadani
23 Jan

2026
23 Jan

'26
6:27 p.m.
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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples of
how to fix them.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Attachments:
attachment.html
(text/html — 3.7 KB)
Show replies by date
Travis Briggs
23 Jan
23 Jan
6:41 p.m.
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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples
of how to fix them.
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
attachment
attachment.html
AntiCompositeNumber
6:42 p.m.
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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples of how to fix them.
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
Travis Briggs
6:55 p.m.
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:
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"
>
And I want to convert it to an actual tag at a smaller size, also
embedding the image binary in our app (Kiwix), I should no longer request
-BMW.svg.png (and then set the width/height attributes to 400px by 320px in
the app), but instead request
-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 -
...
...
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples
of how to fix them.
...
...
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
...
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
_______________________________________________
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
attachment
attachment.html
Brooke Vibber
9:42 p.m.
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:
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
>
And I want to convert it to an actual tag at a smaller size, also
embedding the image binary in our app (Kiwix), I should no longer request
-BMW.svg.png (and then set the width/height attributes to 400px by 320px
in the app), but instead request
*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
attachment
attachment.html
Andre Klapper
8:25 p.m.
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
, "Unless
otherwise noted, the sizes mean width in pixels."
Cheers,
andre
--
Andre Klapper (he/him) | Bugwrangler
bawolff
24 Jan
24 Jan
5:10 a.m.
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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples
of how to fix them.
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
attachment
attachment.html
Sam Wilson
6:37 a.m.
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
" 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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and
examples of how to fix them.
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Wikitech-l mailing list --wikitech-l@lists.wikimedia.org
To unsubscribe send an email towikitech-l-leave@lists.wikimedia.org
attachment
attachment.html
Travis Briggs
25 Jan
25 Jan
4:32 a.m.
Added an "FAQ" section to that article. How does it look now?
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
" 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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples
of how to fix them.
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
attachment
attachment.html
Sam Wilson
5:02 a.m.
Looks great, thanks!
On 25/1/26 12:32, Travis Briggs wrote:
...
Added an "FAQ" section to that article. How does it look now?
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 -

And also documented on MetaWiki -

To help fix the existing instances, please see
examples of how to fix them.

Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list --wikitech-l@lists.wikimedia.org
To unsubscribe send an email towikitech-l-leave@lists.wikimedia.org
_______________________________________________
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
attachment
attachment.html
Amir Sarabadani
20 Apr
20 Apr
12:55 p.m.
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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples
of how to fix them.
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
attachment
attachment.html
bawolff
5:16 p.m.
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 -
And also documented on MetaWiki -
To help fix the existing instances, please see
for search-links, and examples
of how to fix them.
Best
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
attachment
attachment.html
Age (days ago)
91
Last active (days ago)
wikitech-l@lists.wikimedia.org
11 comments
7 participants
tags
(0)
participants
(7)
Amir Sarabadani
Andre Klapper
AntiCompositeNumber
bawolff
Brooke Vibber
Sam Wilson
Travis Briggs