YouTube Thumbnail Downloader

YouTube Thumbnail on Mobile

Your phone is not the problem. On 8 October 2026 we requested the same thumbnail address four times with four different clients — a desktop browser, an Android browser, an iPhone browser and a bare command-line client with no browser at all. All four received the identical file: same byte count, same SHA-1, and the server sent no Vary header at all, meaning it never treated them as different. So a phone does not get a smaller, different or degraded thumbnail. Three things actually decide what you end up with on a phone: which file name you asked for (a miss is a 1,097-byte grey square that your photo app will happily display), whether you asked for the WebP (it was larger than the JPEG in 2 of the 6 pairs measured), and what happens after the download, which is the part the server has no say in.

Four clients, one file

Same address, four different User-Agent strings, each also advertising WebP support. Every response was hashed:

Four rows, two columns, two distinct files — and the two columns are the only difference that matters. The practical consequence: if a thumbnail looks wrong on your phone, the file is not the reason, because it is the same file you would get on a laptop. Either you asked for a name that does not exist (see the grey square below), or you are looking at it through an app that renders it differently.

Asking for WebP from the .jpg address does nothing

A phone browser advertises WebP support on every request, so it is reasonable to assume the server hands it a WebP. It does not. All three .jpg addresses returned JPEG bytes — the file began with FF D8 — even with Accept: image/webp in the request, and no Vary header was present to say otherwise. The WebP copies exist, but at a different address: i.ytimg.com/vi_webp/<id>/<name>.webp. Same .jpg host img.youtube.com also answers that vi_webp path, with identical bytes.

And when you do ask for the WebP, the saving is not guaranteed. Six pairs, both copies of the same video at the same nominal size:

Two of six WebP downloads on mobile data were larger than the JPEG of the same size — one of them by 27 KB. "WebP is the small one" is a habit, not a rule: the two copies are produced separately and the WebP was not always encoded with the same care. If bytes matter, ask for the WebP and check what you got.

What one thumbnail actually costs on mobile data

The name you pick moves the download by a factor of thirty, on the same video. Measured byte counts, shown in KB:

Two traps sit in that table. The obvious one is the last row: default.jpg is 2.8 KB, which is fine for a preview and useless as a picture because it is 120 × 90. The less obvious one is video 2's hq720.jpg at 175.4 KB: the "720" name was 67 KB heavier than maxresdefault on that video. Two names at the same nominal 1280 × 720 resolution are not the same file, and the cheaper-sounding one is not always the smaller one.

The grey square, and why there are two of them

A missing thumbnail is not an error page. The host answers 404 and a picture, so a phone gallery has no way to tell you that the download failed — it shows you a grey square as if it succeeded. From an iPhone client, an ID with one extra character returned 404 · 1,097 B · image/jpeg · 120 × 90, and an upper-cased ID returned the identical file. The same 1,097-byte image, with SHA-1 6e902fa6302eb30c, also came back from the other image host, so the placeholder is a property of the file name being wrong, not of the host.

The second grey square is the one worth knowing about: if you ask for a .webp and it does not exist, you get a different placeholder — 404 · 552 B · image/webp, SHA-1 62302a6f7362641e. Half the size, a different file type, and still a grey square. So the extension you typed decides which of the two fake images you end up saving, and neither is the thumbnail.

This is why the file's size is the fastest check on a phone: anything at or under a kilobyte is the miss, whichever grey square it is. The exact numbers to compare against are on the verification page, and the file names and when they go missing are on the size page.

A stalled download does not have to start over

On a weak mobile connection the useful question is whether a partly-fetched file can be resumed. It can: the host advertises Accept-Ranges: bytes, and a request for the first 2,048 bytes of the 65,324-byte maxresdefault.jpg returned 206 with Content-Range: bytes 0-2047/65324 and exactly 2,048 bytes of body. The WebP path behaves the same way — 206 with Content-Range: bytes 0-2047/28620. So a partial fetch of a thumbnail is legitimate traffic here, which is what a reconnect-and-resume has to rely on.

What is yours to check after the download

1. Size first. Under roughly a kilobyte means the placeholder, and on a phone that is the failure that hides best, because the grey square renders perfectly.
2. Extension second, bytes third. The two formats are genuinely different files, not two names for one: every .jpg address measured here returned bytes beginning FF D8, and every .webp address returned RIFF … WEBP. If an app on your phone refuses to open the file, the extension is the first thing to check.
3. Where it landed. A long-press save happens inside whichever app is hosting the browser, and that app decides where the file goes. If the picture never appears in your photo library, look in the Downloads or Files app before downloading it a second time — the file is not lost, and re-downloading gives you the same bytes.

The tool on the home page names the file that answered and reports its size, so you can see before saving whether you got a real file or one of the two grey squares. How the address itself is built from a paste is on the link page, and what you may do with the picture afterwards is on the usage page.

Questions people actually ask

"Why does the thumbnail come out grey on my phone but not on my computer?"
It comes out grey on both — the bytes are identical on every client measured here, so the download step cannot be what differs. What differs is which step you skipped: on the computer you probably noticed the small file or the wrong file name, and on the phone the grey square just looks like a picture.

"Does my phone get a smaller version of the file than my laptop?"
No. The same address returned 65,324 bytes with the same SHA-1 to a desktop browser, an Android browser, an iPhone browser and a plain command-line client, and the responses carried no Vary header. There is no mobile edition of a thumbnail.

"I asked for the .webp one and got a grey box — why does it look different from the grey box I got last time?"
Because there are two different placeholders. A miss on a .jpg address is 1,097 bytes of JPEG at 120 × 90; a miss on a .webp address is 552 bytes of WebP. Both are grey squares, both are 404s, and neither is your thumbnail.

"Is the WebP always the smaller download on mobile data?"
Not always. In six measured pairs the WebP was smaller four times, saving between 32.8% and 56.2%, and bigger twice — 108,323 bytes of JPEG against 135,454 bytes of WebP for the same video at the same nominal size, and 32,195 against 33,776 on another.

"My download died halfway on mobile data. Do I have to start from zero?"
No — the host supports partial fetches. A ranged request for the first 2,048 bytes came back as 206 with Content-Range: bytes 0-2047/65324, and the WebP path answered the same way against its own 28,620-byte total.

All numbers on this page were measured on 8 October 2026 by requesting thumbnail addresses directly and recording the HTTP status, the response headers, the actual byte count, the SHA-1 of each body and the pixel dimensions read out of each file's own header — 43 requests in total, covering four client identities, six JPEG-to-WebP pairs, ranged requests and misses on both the .jpg and .webp paths. No other source was used, and no volumes, rankings or analytics figures are quoted. Videos are identified by number only — no titles, channel names or watch links appear on this page — and no image from any other site is used or hosted here.