Wikimedia shifts Wikipedia thumbnails to thumb.wikimedia.org with fixed widths and selective WebP

New host, familiar paths

English Wikipedia thumbnails have quietly moved to a new host, and the shift changes several behaviours that scrapers and image tools have taken for granted. According to a dev.to analysis published on 14 November 2026, scaled article images now load from thumb.wikimedia.org instead of upload.wikimedia.org, only a fixed set of thumbnail widths is served, and WebP is delivered to clients that specifically negotiate for it.

The author measured the change with curl against a single file, the Einstein portrait used in the English Wikipedia article, and explicitly notes that one file is a small sample. The error responses, however, point to a published global rule rather than anything specific to the file tested.

The URL structure after the hostname is unchanged: thumb/, the two hash directories, the file name, and a width segment. What is new is the host itself, plus tracking parameters appended to thumbnail links, with utm values referencing en.wikipedia.org and a parser campaign.

The classic trick of recovering the original Commons file, dropping thumb/ and the width segment from the path, still works, but only if the host is also rewritten to upload.wikimedia.org. Requesting the original's path on the thumb host returns a 301 redirect to the Commons home page. The dev.to author notes their browser extension kept working precisely because it already rewrote the host; a rule that only strips path segments would now land users on the Commons homepage.

Only a fixed list of widths is served

Previously, changing the width number in a thumbnail URL to any value returned an image at that width. That no longer holds. Of 14 widths tested one second apart on the new host, 120, 250, 330, 500, 960, 1280, 1920 and 3840 pixels returned images, while 180, 320, 640, 800, 1024 and 2560 returned HTTP 400. An earlier pass also retrieved 20, 40 and 60 pixel images, while 777 and 1200 failed, so the working set appears slightly larger than the tested list.

The 400 response is an HTML error page that directs users to Wikimedia's published list of standard thumbnail sizes, which suggests a global policy rather than a per-file rule.

For arbitrary widths, the Special:FilePath endpoint on Commons still accepts a width parameter and rounds up: a request for 777 pixels resolved through redirects to the 960px thumbnail. Without a width parameter, it resolves to the original file on upload.wikimedia.org.

WebP, but only if you ask for it

The same 500px thumbnail was requested with four Accept headers. curl's default header, image/jpeg alone, and image/avif with a wildcard all returned JPEG at 81,486 bytes. Only image/webp with a wildcard, and Chrome's real Accept header, returned WebP at 73,684 bytes. AVIF without WebP still gets JPEG, so the server appears to switch on WebP specifically.

Two wrinkles stand out. First, the WebP response reportedly carried no Vary header and was a cache hit, so from the outside it is unclear how the caches keep the JPEG and WebP variants apart. Second, any tool that fetches thumbnails with a browser's own headers will receive WebP bytes at a URL ending in .jpg; saving the file under the URL's name produces a mislabelled file. The dev.to author's advice is to sniff the bytes or read the Content-Type header before naming anything. Originals on upload.wikimedia.org still come back as JPEG.

Rate limits arrive fast

A rapid loop of requests drew 429 responses by the fifth request, although the width check appears to run first, since off-list widths still received 400s while listed widths were limited. One-second spacing on the thumb host avoided 429s entirely. Wikimedia's user-agent policy also asks scripted clients to send a descriptive User-Agent with contact details.

Why it matters

Wikipedia's image URLs have been stable for years, and a lot of tooling encodes assumptions about them: downloaders, mirrors, offline readers and archiving scripts. A new host, a fixed width list and content negotiation that can silently change the file format under a .jpg name are exactly the kind of quiet changes that surface as bugs months later. Anyone scripting against Wikimedia images should re-check their assumptions: use the published width list, handle WebP regardless of file extension, expect tracking parameters on thumbnail URLs, and throttle requests with backoff on 429. The missing Vary header is also worth watching, since it affects whether caches can reliably serve the right variant to every client.