In T375981#11423752, @Ladsgroup wrote:

So in terms of the load on the infra, this is not an issue anymore since mediawiki automatically turns them into one of the steps (T360589) so this is merely a css config at this point.

But there is a complexity here, The default is 250px. For users who use below that, we can simply do css. But for larger ones, mediawiki currently is loading 330px (the next larger standard size) and then scale down. So if we fully remove the part and let css take over, the images will become blurry for those users since mw will load 250px.

IMO, the parser should give the same output regardless of user preference, so if we keep this preference, it should be done via CSS. As Ladsgroup mentioned, this would result in users who set their preference above 250px getting blurry images. I can think of two possible solutions:

• Remove all options greater than 250px.
• Have the parser serve a larger thumbnail for everyone and scale it to 250px for logged-out users and those who keep the default preference.

Not sure which of those is best, or if it might be better to remove the user preference entirely, but those are the three best options so far as I can see.

One thing that could be a middle ground is to have "large thumbnail" mode and split the PC into two modes, default and large. Then all other options would simply turn into a css. PC would split into two but better than six/seven. Loading everything with 500px for everyone is a non-starter. The increase would be quite big.

Remove all options greater than 250px.

Yes. I think it would be sensible to remove these.

One thing that could be a middle ground is to have "large thumbnail" mode and split the PC into two modes, default and large. Then all other options would simply turn into a css. PC would split into two but better than six/seven.

I'd be curious to know what % of people are using the 300px and 400px size? Do we know?

Loading everything with 500px for everyone is a non-starter. The increase would be quite big.

What if we also introduced lazy loaded images on desktop (T148047) ? Would that change things? Or is the concern not with the serving of the asset but that generating a 500px is more computationally expensive than 250px?

In T375981#11426268, @Jdlrobson-WMF wrote:

Remove all options greater than 250px.

Yes. I think it would be sensible to remove these.

One thing is that this could be an accessibility vehicle. I have seen people needing to use magnifier tool so they can see text. A bigger image size definitely will help them. Don't know how many people use the large sizes for a11y reasons though.

One thing that could be a middle ground is to have "large thumbnail" mode and split the PC into two modes, default and large. Then all other options would simply turn into a css. PC would split into two but better than six/seven.

I'd be curious to know what % of people are using the 300px and 400px size? Do we know?

Yup, I linked the stats above. According to T106640#10761152 it is 53K users using 400px and 59K users are using 330px

Loading everything with 500px for everyone is a non-starter. The increase would be quite big.

What if we also introduced lazy loaded images on desktop (T148047) ? Would that change things? Or is the concern not with the serving of the asset but that generating a 500px is more computationally expensive than 250px?

I don't think it'll change much but I need data before I can make an assessment in one way or another.

I think having two thumbnail preferences ("normal" and "large/accessible") might solve most issues, although we'd still have the complexity in core of serving HTML with two different sizes. I haven't seen a discussion of responsive images yet: in many cases even though the screen px is fixed, our HTML mentions thumbnails in 3 or so different resolutions based on the screen magnification factor.

In T375981#11430509, @cscott wrote:

I think having two thumbnail preferences ("normal" and "large/accessible") might solve most issues, although we'd still have the complexity in core of serving HTML with two different sizes. I haven't seen a discussion of responsive images yet: in many cases even though the screen px is fixed, our HTML mentions thumbnails in 3 or so different resolutions based on the screen magnification factor.

Oh that's actually a good idea. I don't know how hacky it would be on css side but we can theoretically change the 1x img src on large/a11y mode by taking it from 2x/1.5x and people who are using the large mode won't have responsive images (all img src values being the same). I think that's a good compromise but I don't know whether we'd have to resort to js hacks for this or not.

Change #1227492 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] POC: Serve a single source of HTML with two thumbnail options.

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

@SherryYang-WMF I chatted to Content Transform team about this today (@MSantos and @cscott ). We'd like to find a middle ground where we add support to Parsoid for 2 different thumbnail options (as suggested in {T375981#11424349}. Ideally we'd have one, and scale it down but SRE have said "Loading everything with 500px for everyone is a non-starter" (T375981#11424349)

As part of this work we'd reduce the available preference options to two: standard and large. I'd need some help from Readers Growth with this end of Feb/early March. Bonus points if we could tie this to an A/B experiment relating to serving larger thumbnails by default to see how that impacts our key metrics.

It's in our interest to get Parsoid rolled out as it will mean cheaper experiments in readers growth and doing this proactively will reduce the likelihood of blockers. It also should help addressing urgent needs for de-risking WE4.3, WE5.4, and our infrastructure. I estimate a sprint of work (hopefully 5-8 points tops)

Currently

We have 8 variants of parser HTML as we serve image width and height attributes for each option to support the option.

Proposed

1 variant of parser HTML with 2 supported preferences.

This reduces the number of 330px queries; reduces preference table rows and reduces the parser cache variants from 8 to one provided we are okay with pixelated images until JavaScript kicks in and adding a 4x responsive query. We could serve the same HTML to everyone and add a class to the HTML element that controls the size. Proof of concept patch (patchdemo not working now but I can update later).

Note, we can use 2 variants if we are not okay with the above.

@Ladsgroup would this be a sensible approach to pursue in just over a month from an SRE perpective?

Hi, It would be nice to implement this but it's not really related to T402792 as the served images all are in standard sizes.

For what it's worth, I am one of the 53k users who has the pref set to 400px and in my case it is for accessibility.

I think I would probably be ok with the slight degradation of experience of blurry images until JS or CSS performs the upgrade (would that be onReadyStateComplete? It's a good while since I was doing much UI work myself)

I would worry, however, at the visual impact of the rendered images changing size and causing text reflow; that could be quite disorienting, itself an a11y issue (essentially violating my OS prefers-reduced-motion pref).

Am I worrying too much about a reflow event, given most pages have no default-sized images in the first screen-height? Or are infobox images also generally default-sized?

I'm no expert on this, but my guess is that CSS could scale the image to the right size from the start, even before the JavaScript changes the image source to a larger thumbnail. Thus there would be no text reflow. I could be wrong, though.

@Mr._Starfleet_Command yes that's correct! @OwenBlacker the proposed solution would not have a reflow and you would still get the same experience so no need to worry about a11y, it would just be JavaScript/CSS dependent now. It would also only effect images where no thumbnail size has been requested in the wikitext.

We can ship a solution for Parsoid first to allow editors to give us feedback before applying it to the legacy parser and all page views. Would that help alleviate concerns?

@Mr._Starfleet_Command @Jdlrobson-WMF Oh of course, that completely makes sense.

Yes, it sounds like a sensible plan to ship for Parsoid first. I'd be happy to help beta-test something, if that would be useful.

Given the usage stats in T375981#11527458 it seems like having "small" be 180px would be best to accommodate the 1.7 million users who have that as their preferred thumbnail size.

Current settings in wmf-config default to 250px for every wiki. itwikiquote has an additional option of 360px (for some reason) and svwiki has reduced the number of available default sizes to five (120, 200, 250, 300, 360). T360589 quantized the generated img src for all parsers (including parsoid) so we do already do downscaling via the width attribute for images of specific sizes.

I believe the current plan is to reduce the user thumbnail size preferences to three: "small", "standard", and "large". Small would be 180px, standard is 250px; I'm not sure exactly how large "large" should be, but 300/360/400 seems to be the available options.

In T375981#11604710, @cscott wrote:

Given the usage stats in T375981#11527458 it seems like having "small" be 180px would be best to accommodate the 1.7 million users who have that as their preferred thumbnail size.

FWIW, it's not organic. 180px was the default for a long time and they wanted to change it to 250px for new users, so the default was switched to 250px and every existing user had it back filled to 180px. For really long time, I‌ thought German Wikipedia has a weird default for thumbnails until I realized it wasn't my decision. Once cleaned, the wiki looked normal to me.

Change #1238463 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] POC: Set thumbnail sizes via config

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

After the clean up of user properties (T406724). The number of users that have their thumb set to 180px is now down to 150K in enwiki. I assume overall, it should be around 500K at most.

Change #1227492 merged by jenkins-bot:

[mediawiki/core@master] Support CSS/JS thumbnail sizing in Parsoid

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

The patch for this task caused a regression in production and was reverted: T417828: Some images become disproportionately big in 1.46.0-wmf.16.

In T417828#11630071, @cscott wrote:

This was part of an experiment to support user-customizable thumbnail sizes in Parsoid output (T375981: Preferences settings for small image size are not being respected for Parsoid Read Views). Parsoid sets mw-default-size to indicate images which don't have a width or height set in the wikitext, which are generally then used at the wiki's default thumbnail size. The thing we missed in review was that this applies *only if the image is natively larger than the default thumbnail size*; we never upscale an image to meet the default thumbnail size.

This is probably a deficiency in Parsoid's Mediawiki DOM Spec output: although we have the information about the native image size available (in the data-file-width and data-file-height attributes), I don't believe CSS can natively do a "less than" query on these attribute values, so there's no way to write the "correct" CSS here. I think Parsoid is going to have to either:

1. Only emit the mw-default-size class for images that are greater than/equal the thumbnail size, or
2. Add a separate class for "not upscaled" images, so that the CSS can know to leave them alone.

There's an added wrinkle here, in that the "thumbnail size" is user-customizable. So if the user thumbnail size preferences are 180, 250, and 400 (say), images which are 200px wide will be scaled down for the "small" thumbnail size preference but not scaled up for the "standard" and "large" preferences. Similarly, and image which is natively 300px will be scaled down for small and standard thumbnail size preferences but not for the 'large' one. These breakpoints are going to have to be hardcoded in Parsoid as well if it is to emit classes to distinguish these cases. Hmm.

Some proposed solutions:

1. Add mw-not-upscaled class to images with a "natural size" less than the default thumbnail size (250px in this case). This still leads to slightly different behavior between legacy and Parsoid for images with sizes in between the smallest and largest thumbnail size, but I think that's probably acceptable. For example, a 200px image would be rendered at 200px, even if the user selected "small" thumbnail size (usually 180px), whereas legacy would scale it down for "small" but leave it natural for "standard" and "large" thumbnail sizes. Similarly, a 300px image would be scaled to match the selected thumbnail size (including upscaling to 400px for "large") whereas the legacy behavior would be to scale it down for small and standard but leave it as its natural size for "large" thumbnail size. I think these slightly different behaviors would be acceptable; they would only be visible to users with non-default thumbnail size preferences.

2. An alternative would be to create separate classes for mw-not-upscaled-small, mw-not-upscaled-standard and mw-not-upscaled-large based on the wiki size breakpoints (currently 180px, 250px, and 400px), which would allow exact reproduction of the legacy behavior, at the cost of more complexity in the CSS, HTML, and code. (Images below 180px would get mw-not-upscaled-small and would never be rescaled to the thumbnail size preference; images between 180px and 249px would get mw-not-upscaled-standard and would get only get rescaled to the default thumbnail size if the user's thumb preference is "small"; images between 250px and 399px would get mw-not-upscaled-large and would get rescaled to the default thumbnail size unless the user's thumb preference is "large".)

3. Leave the HTML alone, but use the existing intersection observer on images to suppress scaling (it could add the same mw-not-upscaled class) based on the data-file-width attributes on the image.

I think we should go with option 3. It doesn't require changing Parsoid, the HTML spec, and also doesn't introduce infrastructure-config-based classes into the output HTML. We should use JS to look up the data-* attributes and add the appropriate CSS classes.

I dont think 3 works here will work without some kind of performance penalty e.g cumulative layout shift.

Can we not change the CSS selectors to .mw-default-size[data-file-width=250] or .mw-default-size[width=250] ? I think this would be equivalent to 1.

Change #1240756 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Fix CSS/JS thumbnail sizing in Parsoid: don't upscale small images

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

@Jdlrobson ok, implemented your idea in Fix CSS/JS thumbnail sizing in Parsoid: don't upscale small images (1240756).

(data-file-width would do the wrong thing, since that is 'natural width', but I've tested that [width=250] works as you'd expect. As described in option 1, there are some corner cases where we don't rescale but I think they are reasonable.)

Change #1240756 merged by jenkins-bot:

[mediawiki/core@master] Fix CSS/JS thumbnail sizing in Parsoid: don't upscale small images

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

@Arlolra notes that this CSS/JS solution also doesn't scale images which use the upright option ( https://www.mediawiki.org/wiki/Help:Images#Syntax ). That's not a regression -- we didn't scale those thumbnails before because we didn't scale any thumbnails -- and might be something we address with a new wikitext option, like square. CF Add a new image option: "square" (120856), T351: RfC: Square bounding boxes, T65903: Thumbnails should use a square bounding box by default, T37756: Image parameter for thumbs that scale to an exact box, cropping as necessary, T65904: The 'upright' option should use a square bounding box, T9003: Allowthumbnail size of an image to be defined as proportion of the user's default, etc.

https://en.wikipedia.org/wiki/Wikipedia:Image_use_policy#Displayed_image_size is relevant, too.

It might be that a JS intersection observer is necessary to handle the arbitrary scaling possible with 'upright'.

Hi @Mr._Starfleet_Command and @OwenBlacker could you try this out for us? If you enable parsoid do thumbnails now work how you'd expect?

I'm afraid it does not.

If I go look at the London on enwiki, I'm seeing some images larger (perhaps because they have hardcoded sizes?) but below is what I'm seeing in the History section.

All sizes are what Chrome dev tools are telling me; ❌ are noting differences I would not expect, ✅ are where Parsoid is using a different intrinsic image size from the Legacy parser, but is still downscaling to the render, which is the behaviour I was expecting to see. No emoji indicates no change between the 2 parsers.

I note that the Canaletto image (3rd in that list) and the Royal Exchange photo (8th) are being upscaled by Parsoid, but downscaled by the Legacy parser. To my (aging) eyes, the Canaletto Parsoid upscale look slightly sharper but the reverse is true for the Royal Exchange TIFF, for what it's worth 🤷🏼

On a simpler example, City Hall, London (Newham) on enwiki is showing me a 440 × 225 version of File:Siemens Crystal Building, London.jpg in the infobox on the Legacy parser, but Parsoid is showing me a 280 × 162 image, both being downscaled from 960 × 557.

@OwenBlacker thanks for looking. I am seeing slight differences in the numbers you are sharing. What dpi and thumbnail preference are you testing on?
With 400px set, inspecting File:Westminster Abbey by Canaletto, 1749.jpg I see 500 × 488 px for legacy as intrinsic size in Parsoid and 960 × 937 px for legacy.

You said before "For what it's worth, I am one of the 53k users who has the pref set to 400px and in my case it is for accessibility." so to be precise I'm keen to know what specifically here impacts your accessibility needs? I'm not looking to get the numbers exact, but in similar ballpark. We should be able to get File:Westminster Abbey by Canaletto, 1749.jpg and File:Fotografi av Royal Exchange. London, England - Hallwylska museet - 105857.tif using high resolution images in Parsoid.

Regarding Siege of London, File:Great Fire London.jpg, File:Edward Angelo Goodall04.jpg: While working on this we uncovered some weirdness in how upright works (flagged here: T375981#11641808) that we are thinking through.

@cscott I have some questions based on this example:

On a simpler example, City Hall, London (Newham) on enwiki is showing me a 440 × 225 version of File:Siemens Crystal Building, London.jpg in the infobox on the Legacy parser, but Parsoid is showing me a 280 × 162 image, both being downscaled from 960 × 557.

I'm a bit confused why legacy scales this one - as the infobox itself is specifying this should render at 280px and the thumbnail preference is not supposed to tweak images with specified width. Any idea what might be happeneing here? Is this a bug in legacy?

2. something seems to be off here in the Parsoid output. Legacy parser has a srcset of //upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/960px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 1.5x

Whereas Parsoid has a srcset of //upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/500px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/500px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 2x e.g. 1.5x and 2x are identical.

I would expect Parsoid to output 500px for 1.5x and 960px for 2x
e.g.
//upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/500px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/7/79/Westminster_Abbey_by_Canaletto%2C_1749.jpg/960px-Westminster_Abbey_by_Canaletto%2C_1749.jpg 2x

T419927: PNGs are being displayed at a too-low, blurry resolution was fixed very recently and just backported today Revert "mediawiki.util: Prefer prev step over non-standard in adjustThumbWidthForSteps" (1253518) · Gerrit Code Review

I wonder if that might explain some of your inconsistent results.

Parsoid uses the core imageinfo APIs, and so in theory should be getting exactly the same srcset that core is getting, but given that this code base is (apparently) under active development, it might be safest to use ?action=purge to ensure that you're actually testing the same thumbnail code on Parsoid and legacy at the same time.

Change #1254377 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Skins: Address issue with blurry images for large thumbnails

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

@Jdlrobson-WMF The specific accessibility issue is just poor eyesight, even when corrected by glasses. I have a global pref set for 400px thumbnails and both then and now I am using my dayjob 14" MacBook Pro M5 on “Apple XDR Display (P3-1600 nits)”, if that helps? When I tell it to show resolutions as a list, it says I'm running at the default 1512×982.

Incidentally, I saw another curiosity about image sizing just now (which I can raise as a separate ticket if you need). I was looking at enwiki:Éric_Hazan and the infobox image is being stretched by a style rule from https://en.wikipedia.org/w/load.php?lang=en&modules=ext.cite.parsoid.styles%7Cext.cite.styles%7Cext.echo.styles.alert%2Cbadge%7Cext.uls.interlanguage%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediamessages.styles%7Cext.wp25EasterEggs.styles%7Cjquery.makeCollapsible.styles%7Cmediawiki.skinning.content.parsoid%7Coojs-ui.styles.icons-alerts%7Cskins.vector.icons%2Cstyles%7Cskins.vector.search.codex.styles%7Cwikibase.client.init&only=styles&skin=vector-2022 , reading

html.skin-theme-clientpref-thumb-large .mw-parser-output[data-mw-parsoid-version] .mw-default-size img {
    width: 400px;
}

without which Chrome Inspector says the img has a width of 249.702px

I took a screenshot and uploaded it as c:File:Example of Parsoid image rendering bug 2026-03-19.png

Clicking through to other articles, it looks like all infobox images are being similarly stretched

Incidentally, I saw another curiosity about image sizing just now

Thanks to your feedback I already found this one (and a related issue) which should be fixed in the patch above (https://gerrit.wikimedia.org/r/1254377). This will not help images using upright which I'm still thinking through but it should reduce the blur factor for you on some images.

Hoping to improve this for you over the next 1-2 weeks!

Change #1254377 merged by jenkins-bot:

[mediawiki/core@master] Skins: Address issue with blurry images for large thumbnails

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

Change #1255774 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/services/parsoid@master] Add `class` and `style` attributes for upright images

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

Change #1255881 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@wmf/1.46.0-wmf.20] Skins: Address issue with blurry images for large thumbnails

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

Change #1255881 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.20] Skins: Address issue with blurry images for large thumbnails

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

Mentioned in SAL (#wikimedia-operations) [2026-03-19T21:22:24Z] <jdlrobson@deploy2002> Started scap sync-world: Backport for [[gerrit:1255881|Skins: Address issue with blurry images for large thumbnails (T375981)]]

Mentioned in SAL (#wikimedia-operations) [2026-03-19T21:24:17Z] <jdlrobson@deploy2002> jdlrobson: Backport for [[gerrit:1255881|Skins: Address issue with blurry images for large thumbnails (T375981)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-03-19T21:29:27Z] <jdlrobson@deploy2002> Finished scap sync-world: Backport for [[gerrit:1255881|Skins: Address issue with blurry images for large thumbnails (T375981)]] (duration: 07m 03s)

@OwenBlacker this should be working a lot better now. There is still a lack of support with upright parameter but working on that in T420657: Preferences settings for small image size are not compatible with upright for Parsoid Read Views. Do things seem less blurry now? (Sorry I'm starting to sound like your optician!)