Couldn’t the non-standard URLs redirect to the standard ones? So that if I write

<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/b/b4/Symbol_star_gold.svg/15px-Symbol_star_gold.svg.png" style="width:15px">

I get a 15px wide icon, for which the browser automatically downscales https://upload.wikimedia.org/wikipedia/commons/thumb/b/b4/Symbol_star_gold.svg/20px-Symbol_star_gold.svg.png.

In external tools, maintaining a list of supported thumbnail sizes is a large burden. Of course, not blocking URLs means that during the transition period, the breakage is less obvious (the thumbnails do appear, they are just larger than necessary if no width is specified in CSS), but I think it’d be worth it in the long run. Serving some redirects is not that big of a burden on the infrastructure as serving all the resized images is, so I hope it’s acceptable performance-wise.

The URL to our thumbnails is not an stable API‌ and shouldn't be treated as such. The actual APIs return URL to turn to nearest larger standard size and if the programmer really cares, they should use that instead of hard-coding the URL. For example https://commons.wikimedia.org/w/api.php?action=query&titles=File:Albert%20Einstein%20Head.jpg&prop=imageinfo&iiurlwidth=100&iiprop=url

In the long term, what you're asking is basically T66214: Define an official thumb API

I see. However, people have been treating it as a stable API, and there are also just too many places where using the action API is straight impossible – for example, style files (including TemplateStyles and styles-only gadgets/user scripts, but also third-party style files). I’m glad that an easier-to-use API is proposed in T66214, but looking at the activity on that task, I guess removing arbitrary-size thumbnail generation can’t wait for it. Couldn’t the redirects be an interim solution until the official thumb API is ready?

I just fixed https://en.wikipedia.org/wiki/User:Bradv/Scripts/ExpandDiffs.js#L-20 which was previously showing a blank space (since it was hooking into an image stored in the skin that had evacuated elsewhere).

Please suggest an appropriate fix for this script. I am fairly certain directly changing the CSS block associated with the relevant pair of images would not be an appropriate fix. And 20px certainly would not be.

In T414805#11555784, @Izno wrote:

https://en.wikipedia.org/wiki/User:Bradv/Scripts/ExpandDiffs.js#L-20 […]

.difftoggle {
    background-image: url(https://upload.wikimedia.org/wikipedia/commons/thumb/d/d0/ArrowDown.svg/8px-ArrowDown.svg.png);
    background-repeat: no-repeat;
    background-position: left bottom;
    width: 15px;
    height: 15px;
    display: inline-block;
    cursor: pointer;
}

Please suggest an appropriate fix for this script. […]

One of the reasons that we don't redirect non-standard URLs is that it breaks compatibility and expectations in CSS rendering. At a low rate, these may not be a problem long-term, but migrating indeed involves more than just changing the image URL which should not be replaced en-mass unless you understand or have tested each usage in-situ.

For CSS, you can use background-size to control how it renders. These are the equivalent to <img width=""> attributes. For example, you can use:

.difftoggle {
  background: url(https://upload.wikimedia.org/wikipedia/commons/thumb/d/d0/ArrowDown.svg/20px-ArrowDown.svg.png) left bottom no-repeat;
  background-size: 8px; /* image width */
}

Are icons really a problem? I mean, are there actually external sites using images loaded from Wikimedia as icons on their pages?
In most applications, I’d use sprites (for old school webapps) or icon fonts in new apps. I would imagine people would rather use Font Awesome that is easy to setup and looks uniform rather then using very hard to find icons from Commons. Did you check where does the request for small images come from?

Could you perhaps consider making an exception for icons 32px and smaller that are loaded from Wikimedia and Wikipedia sites? Perhaps also include toolforge.
I checked plwiki and found over 40 scripts or pages using images below 20px, so 20px doesn’t seem to be a real standard. I’d argue that, in the icon domain, sizes like 16, 32 and 48px should be much more common. Though I just checked images below 20 for now.

Found two problems with the migration:

1. The docs for the editor suggest using 22px (though I guess you can replace that with 20px in most cases): https://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization#Add_a_button_to_an_existing_toolbar_group
2. If you do want a specific size, there seems to be no way to provide it in this API.

An example from a user:
https://pl.wikipedia.org/wiki/Wikipedysta:S%C5%82awek_Borewicz/WerToolbar.js#L-15

If I were migrating that now, I would use SVG, but SVG doesn't work in this case (as there’s no way to specify the icon size). I mean this looks terrible 🙃

icon: 'https://upload.wikimedia.org/wikipedia/commons/6/61/Contribs_icon-black.svg',

why not simply using https://upload.wikimedia.org/wikipedia/commons/thumb/6/61/Contribs_icon-black.svg/20px-Contribs_icon-black.svg.png Is 1px causing issues?

Because SVG is sharp on any dpi/ppi.

22px is the button size reserved by WikiEditor. Any different size will look off in the interface, including 1px off. The problem isn't the size of the image file, it is the size of the rendering. WikiEditor lacks a suitable default background-size, and also does not expose a way to set it declaratively through the Toolbar API. This is a bug in WikiEditor.

Once fixed, I'd recommend using a 40px file (or SVG, where suitable), because it will look fuzzy/blurry on HiDPI screens otherwise. This isn't an option today, because the image would be either too small within its box, or clipped and cut off.

To double check, should it be background-size: cover;?

In T414805#11558341, @Ladsgroup wrote:

To double check, should it be background-size: cover;?

No, that would stretch and crop the image by default, which will look weird.

background-size: contain; might be a slightly better fit, because it would only scale down if needed, but never upscale or crop.

However, that doesn't work either, because the button element is 32x32 where the design expects an icon of 22x22px to be centered inside that area, with the remaining space functioning as padding. Otherwise it would look very crammed.

Vector:

Monobook:

So what you want is background-size: 22px;, which controls the rendered image width, like <img width=""> would.

Change #1233759 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/WikiEditor@master] Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1233759

Mentioned in SAL (#wikimedia-operations) [2026-02-04T16:13:44Z] <Amir1> bumping rate limit of non-standard thumb sizes to medium browser score (T402792 T414805)

MediaViewer got broken by this. ☹ For example, https://commons.wikimedia.org/wiki/Category:F%C5%91_Street_15_(Budapest)#/media/File:Eclectic_building_(_1886)._Bem_quay_side._Facade._-_15_F%C5%91_Street,_Budapest.JPG generates an HTTP 429 on my 1920×1088px viewport. Is there a task specifically tracking that extension?

In T414805#11589974, @Tacsipacsi wrote:

MediaViewer got broken by this. ☹ For example, https://commons.wikimedia.org/wiki/Category:F%C5%91_Street_15_(Budapest)#/media/File:Eclectic_building_(_1886)._Bem_quay_side._Facade._-_15_F%C5%91_Street,_Budapest.JPG generates an HTTP 429 on my 1920×1088px viewport. Is there a task specifically tracking that extension?

I'm sure we adjusted mediaviewer but maybe a number is wrong somewhere. Let me dig.

This image is in a standard size and passes through our rate limit: https://upload.wikimedia.org/wikipedia/commons/thumb/8/8f/Eclectic_building_%28_1886%29._Bem_quay_side._Facade._-_15_F%C5%91_Street%2C_Budapest.JPG/1280px-Eclectic_building_%28_1886%29._Bem_quay_side._Facade._-_15_F%C5%91_Street%2C_Budapest.JPG

Maybe another rate limit somewhere else? Can you get the 429 response body?

I‌ think this should fix it: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1237517 but I‌ need to get an opinion of an expert in MediaViewer on it before merging.

In T414805#11591625, @Ladsgroup wrote:

Can you get the 429 response body?

I don’t get 429 anymore. I can try to find another one, but do I interpret T414805#11591828 correctly that you don’t need it anymore? If I get it somewhere randomly, I’ll make sure to save it in any case.

I have reverted the rate limit for "medium" browser score before the weekend to reduce disruptions to people. We have collected enough data points to know what to fix next but once we re-enable it and you see it again, make sure to get 1- The URL you're getting the error 2- The response body. Thanks!

Change #1237927 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/MultimediaViewer@master] thumbUrl: Adjust the samll size to match common standard sizes

https://gerrit.wikimedia.org/r/1237927

In T414805#11591828, @Ladsgroup wrote:

I‌ think this should fix it: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1237517 but I‌ need to get an opinion of an expert in MediaViewer on it before merging.

This is deployed now. Based on turnilo and webrequest data: We have around 27M requests to non-standard sizes daily [1], and 5M are to 2560px which would be fixed with this patch (caches need to expire but, it should be done soon).

[1] The number might look quite large but 1- It's 1% of requests to upload cluster 2- Majority of them are scrapers or similar. In fact, we issue more 429s than 200s for non-standard sizes (429s are not counted in the above stats)

Mentioned in SAL (#wikimedia-operations) [2026-02-11T13:28:09Z] <Amir1> re-enabling rate limit of non-standard thumbnail sizes on medium browser score (T414805 T402792)

Change #1237927 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] thumbUrl: Adjust the samll size to match common standard sizes

https://gerrit.wikimedia.org/r/1237927

Change #1239157 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/MultimediaViewer@wmf/1.46.0-wmf.14] thumbUrl: Adjust the samll size to match common standard sizes

https://gerrit.wikimedia.org/r/1239157

Change #1239158 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/MultimediaViewer@wmf/1.46.0-wmf.15] thumbUrl: Adjust the samll size to match common standard sizes

https://gerrit.wikimedia.org/r/1239158

Change #1239158 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@wmf/1.46.0-wmf.15] thumbUrl: Adjust the samll size to match common standard sizes

https://gerrit.wikimedia.org/r/1239158

Change #1239157 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@wmf/1.46.0-wmf.14] thumbUrl: Adjust the samll size to match common standard sizes

https://gerrit.wikimedia.org/r/1239157

Mentioned in SAL (#wikimedia-operations) [2026-02-12T16:31:11Z] <ladsgroup@deploy2002> Started scap sync-world: Backport for [[gerrit:1239158|thumbUrl: Adjust the samll size to match common standard sizes (T414805)]], [[gerrit:1239157|thumbUrl: Adjust the samll size to match common standard sizes (T414805)]]

Mentioned in SAL (#wikimedia-operations) [2026-02-12T16:33:16Z] <ladsgroup@deploy2002> ladsgroup: Backport for [[gerrit:1239158|thumbUrl: Adjust the samll size to match common standard sizes (T414805)]], [[gerrit:1239157|thumbUrl: Adjust the samll size to match common standard sizes (T414805)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-02-12T16:38:48Z] <ladsgroup@deploy2002> Finished scap sync-world: Backport for [[gerrit:1239158|thumbUrl: Adjust the samll size to match common standard sizes (T414805)]], [[gerrit:1239157|thumbUrl: Adjust the samll size to match common standard sizes (T414805)]] (duration: 07m 37s)

Change #1233759 abandoned by Ladsgroup:

[mediawiki/extensions/WikiEditor@master] Set background-size for toolbar buttons

Reason:

I don't have capacity to work on it right now. Someone else should look into it.

https://gerrit.wikimedia.org/r/1233759

In T414805#11612140, @gerritbot wrote:

[mediawiki/extensions/WikiEditor@master] Set background-size for toolbar buttons

https://gerrit.wikimedia.org/r/1233759

@MatthewVernon Based on discussions with SRE for T414338: Identify the provenance of image requests, I believe tiny icons are not our focus. Is that right? The long tail in CSS for gadgets, tools, apps, user scripts, extensions, etc to update and chase down to avoid broken UI makes this a daunting effort that I'm not sure is worth taking on righ tnow.

Could we amend the initial restriction proposed here to say that widths under 60px remain permitted? We can continue to treat these as non-standard and apply low limits to their cache misses, but we would continue to treat them as syntactically valid URLs that can be served from the cache, and at a low rate for regeneration.