I don't think the issue is specific to infoboxes, you might just notice it more often in infoboxes if rowiki use sizes not supported by T375981: Preferences settings for small image size are not being respected for Parsoid Read Views

There are similar bug reports on dewiki about images outside of infoboxes having a huge padding in Parsoid read mode:
https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Weißer_Rahmen_um_Bilder
https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia/Archiv/2026/Woche_15#Skalierung_bei_Bildern_stimmt_nicht

Could you include some screen shots? You can just cut-and-paste them here into Phab. I can't reproduce that locally. What skin are you using? Perhaps that matters? Also, do you have a custom thumbnail size set?

Also, can you reproduce it using ?useparsoid=0 vs ?useparsoid=1 outside of the migration tool? Just to try to see if this is a bug specific to the migration tool.

I suspect you are actually seeing T417513: Switch to CSS/JS solution for thumbnail size in legacy parser which is a migration to "only three" thumbnail size preferences gradually rolling out on both Parsoid and legacy as a response to the huge increase in thumbnail traffic from AI scrapers. If you reset your thumbnail size preference to the default, do you still see differences?

(There's also a bug fix in CSS thumbnail scaling: round 'upright' size to nearest 10px (1269534) which fixed a slight rounding bug with upright image sizing, which just rolled out yesterday with wmf.24, but the CSS you cited above is the updated CSS that rolled out with that fix.)

Also, can you reproduce it using ?useparsoid=0 vs ?useparsoid=1 outside of the migration tool? Just to try to see if this is a bug specific to the migration tool.

Yes:
?useparsoid=0

?useparsoid=1

In T423676#11833611, @cscott wrote:

Also, do you have a custom thumbnail size set?

Yes: 300px.

I suspect you are actually seeing T417513: Switch to CSS/JS solution for thumbnail size in legacy parser which is a migration to "only three" thumbnail size preferences gradually rolling out on both Parsoid and legacy as a response to the huge increase in thumbnail traffic from AI scrapers. If you reset your thumbnail size preference to the default, do you still see differences?

I'm very confused by this part. I saw the announcement about the standardization of thumbnails, but my understanding was that MW will just serve a larger thumbnail and the browser will scale down. What I see is it servers bigger thumbnails, but of different sizes depending on the parser. I don't know what is the default for the size, but anything under 300px works, as both parser serve the 500px image.

If this is the bug I'm actually hitting, there are 2 concerns I'd like to raise:

• deploying the Parsoid solution to the legacy parser might break the display for users like me; I'd very much appreciate a solution for this behavior before that is deployed
• I chose 300px specifically because this is the Infobox size on rowiki, meaning the pictures below the infobox are nicely aligned, while the infobox image fills the table. What would be the best way to obtain the same behavior with the 3 fixed sizes?

I'm very confused by this part. I saw the announcement about the standardization of thumbnails, but my understanding was that MW will just serve a larger thumbnail and the browser will scale down. What I see is it servers bigger thumbnails, but of different sizes depending on the parser. I don't know what is the default for the size, but anything under 300px works, as both parser serve the 500px image.

If you have 300px set, you will now receive a thumbnail that renders at 400px. You can add CSS to downsize it but unfortunately we can't officially support more than three thumbnail sizes sustainably. We will be supporting "smaller than default", "default" and "larger than default".

This seems like a browser quirk and probably an upstream Firefox issue once we have reproduction steps. The image is being scaled down unexpectedly due to the rule object-fit: scale-down; in Firefox but working expectedly in Chrome. To workaround it add the following CSS:

.infocaseta img {object-fit: contain; }

minimum test case. Interestingly its the srcset that trips up Firefox...

<!DOCTYPE html>
<html>
    <head>
        <style>
            table {
                border: solid 4px black;
            }
            img {
                border: solid 5px red;
            }
            .mw-default-size img[width="250"] {
                width: 400px;
                height: auto;
                object-fit: scale-down;
            }
        </style>
    </head>
    <body>
        <table>
            <tbody><tr><td colspan="2">
            <span class="mw-default-size"><img srcset="https://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Biserica_%E2%80%9E%C3%8En%C4%83l%C8%9Barea_Domnului%E2%80%9D_%284%29.jpg/500px-Biserica_%E2%80%9E%C3%8En%C4%83l%C8%9Barea_Domnului%E2%80%9D_%284%29.jpg 2x"
            src="https://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Biserica_%E2%80%9E%C3%8En%C4%83l%C8%9Barea_Domnului%E2%80%9D_%284%29.jpg/500px-Biserica_%E2%80%9E%C3%8En%C4%83l%C8%9Barea_Domnului%E2%80%9D_%284%29.jpg" height="167" width="250">
            </span>
            </td></tr></tbody>
        </table>
        <table>
            <tbody><tr><td colspan="2">
            <span class="mw-default-size"><img 
            src="https://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Biserica_%E2%80%9E%C3%8En%C4%83l%C8%9Barea_Domnului%E2%80%9D_%284%29.jpg/500px-Biserica_%E2%80%9E%C3%8En%C4%83l%C8%9Barea_Domnului%E2%80%9D_%284%29.jpg" height="167" width="250">
            </span>
            </td></tr></tbody>
        </table>
    </body>
</html>

Is it something we can workaround with a -moz-object-fit: contain or something like that?

No. Looking closely this issue also impacts Safari, so it would be good to first establish who's bug this is before deciding how to adapt. We can remove the line altogether and reopen T421524: Images with an original size less than 400px are scaled up by large thumbnail preference if we judge this bug (downscaled images) is more severe (than upscaled blurry images).

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

[mediawiki/core@master] Revert "Skin: Avoid stretching low resolution images"

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

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

[mediawiki/core@wmf/1.46.0-wmf.24] Revert "Skin: Avoid stretching low resolution images"

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

Change #1275529 merged by jenkins-bot:

[mediawiki/core@master] Revert "Skin: Avoid stretching low resolution images"

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

Change #1275540 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.24] Revert "Skin: Avoid stretching low resolution images"

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

Mentioned in SAL (#wikimedia-operations) [2026-04-20T23:10:39Z] <jdlrobson@deploy1003> Started scap sync-world: Backport for [[gerrit:1275540|Revert "Skin: Avoid stretching low resolution images" (T421524 T423676)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-20T23:12:21Z] <jdlrobson@deploy1003> cscott, jdlrobson: Backport for [[gerrit:1275540|Revert "Skin: Avoid stretching low resolution images" (T421524 T423676)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-20T23:16:36Z] <jdlrobson@deploy1003> Finished scap sync-world: Backport for [[gerrit:1275540|Revert "Skin: Avoid stretching low resolution images" (T421524 T423676)]] (duration: 05m 56s)

In T423676#11842022, @Jdlrobson-WMF wrote:

Okay we reverted the change.

I want to file a Bugzilla upstream patch against Mozilla before I close this out for completeness.

This has improved the look, but has not solved the difference between parsers unfortunately. Which task tracks the fact that the old parser fits the image in the table size, but the new one doesn't?

This has improved the look, but has not solved the difference between parsers unfortunately. Which task tracks the fact that the old parser fits the image in the table size, but the new one doesn't?

For anonymous users: https://ro.wikipedia.org/wiki/M%C4%83n%C4%83stirea_Golia?useparsoid=1 and https://ro.wikipedia.org/wiki/M%C4%83n%C4%83stirea_Golia?useparsoid=0 look identical.

For logged in users the image fits the container in both instances.. but given your thumbnail preference it will appear as 300px in legacy parser, 400px in Parsoid. That is not going to be fixed.

If you want the infobox itself to be constrained to 300px (rather than to expand to the size of the thumbnail inside it), you need to add the following rule to your infobox template:

.infocaseta img {
  max-width: 100%;
  height: auto;
}

Note, in legacy parser if you set thumbnail size to 400px, you are already getting a 400px infobox, so this is an existing bug/feature in that template.