YouTube Thumbnail Downloader

YT Thumbnail Downloader

A yt thumbnail downloader does one thing: it takes the video ID out of the link you paste and asks YouTube's image host for one of the picture files that the video already publishes. No key, no account, no API call — the whole job is https://img.youtube.com/vi/<video-id>/<file-name>.jpg. What decides whether you get a picture or an 120 × 90 grey square is the file name you ask for, not the tool. So we measured the name list twice, one day apart: 116 requests on 2 October 2026 and the same 116 on 3 October 2026, across four videos. Of the pairs that could be compared like for like, 114 of 114 came back byte-for-byte identical — same SHA-1, same byte count, zero status changes. This page is that run, plus the names that behave unlike their reputation.

What "downloader" means here, exactly

• It fetches bytes, it does not render anything. The picture is a file that the host serves; a downloader saves it. There is no resize step and no "extract from the video" step, because the still already exists as a published file.
• It cannot give you a frame of your choosing. What you receive is the still the uploader's video was published with — plus, if you know the numbered names, other stills the host keeps. The video itself is never decoded.
• It is a name-guessing problem. The ID is fixed by the link; the only variable you control is which file name you append. Every failure on this page comes from that choice, not from the download.

The names that answered, measured 3 October 2026

Four videos, eight file names, one request each. Status, byte count and the pixel size read out of the downloaded file's own header:

Read the last two rows next to the first row. On dQw4w9WgXcQ, oar2.jpg is 10,356 bytes larger than maxresdefault.jpg and 640 pixels wider — and it is not on the six-name list most downloaders offer. On jNQXAC9IVRw the same name came back 320 × 240, because oar follows the upload's own frame shape, not a fixed template. Its measured range across these four videos is 14,919 B to 83,660 B and 320 × 240 to 1920 × 1080, which is exactly why a fixed list of six names cannot cover it.

We asked the same 116 questions a day later

The useful question for anyone building or trusting a downloader is not "which names exist" but "how long does what I learned stay true". So the same 116 requests (four videos × 29 names, plus ID-case variants) were sent on 2 October 2026 and again on 3 October 2026, and each response was hashed.

• 114 pairs compared like for like (same file, same URL). All 114 were byte-for-byte identical: same SHA-1, same byte count. Zero status changes, zero content changes in 24 hours.
• The remaining two rows are excluded on purpose: the day before they were measured against a different host, so they are not a like-for-like pair and claiming them as "changed" would be wrong.
• The response header on these files was Cache-Control: public, max-age=7200 — two hours. That is a caching window, not a claim about the file's lifetime, and it is worth knowing because it means a repeated request may legitimately be served from cache.
• Every one of those files also carried Access-Control-Allow-Origin: *, which is the header that lets a page read the bytes instead of only displaying the picture.

So for this set, what a downloader learned on one day held on the next: the byte counts, the pixel sizes and the status codes were stable, and the thing that actually varies is between videos, not between days.

Two names that are not the same file

Many pages state that hq720.jpg and maxresdefault.jpg are one file under two names. That is sometimes true — and on one of the four videos measured it was false by 71,315 bytes:

The practical consequence: a downloader that treats the two names as aliases and skips one of them can hand you the smaller file and never tell you. Ask for both and keep the larger, or read the byte count and decide — the sizes above were taken on 3 October 2026 and are what the host actually returned that day.

Why a 404 can look like a successful download

When a name does not exist, the host still answers with a real image: a 1,097-byte grey JPEG, 120 × 90, served with a normal 200-style image content type as far as the browser's <img> element is concerned. A downloader that waits for the <img> to load instead of reading the HTTP status will save that grey square and report success. On the old upload measured here, maxresdefault.jpg, hq720.jpg and sddefault.jpg all answered 404 with those same 1,097 bytes, while hqdefault.jpg answered normally at 15,921 B · 480 × 360. Two consequences worth carrying into any script:

• The status code is the answer; the picture is not. 1,097 bytes and 120 × 90 is the shape of a miss, not a thumbnail.
• "The biggest name always exists" is wrong. On that upload the largest surviving file was 480 × 360 — every larger name was gone, and the video is still perfectly public.

What you may do with the file

Saving the bytes is the easy half. The picture belongs to whoever uploaded the video, and it is served from the platform's own host — nothing here stores, mirrors or re-uploads any thumbnail. Your own uploads are yours. For someone else's, treat a saved file as reference material unless you have permission, and check what your jurisdiction allows before you publish it. This is not legal advice.

Questions people actually ask

"I downloaded it and got a grey square that says 120 × 90 — did the video lose its thumbnail?"
Probably not. That square is the miss. It is 1,097 bytes, and it arrives for a name the host does not have. Check the status code of your request; on the old upload measured here three of the six usual names answered exactly that way while the video was still live and public.

"Is maxresdefault always the biggest file I can get?"
No. On 3 October 2026, one video returned oar2.jpg at 75,680 B and 1920 × 1080 against maxresdefault.jpg at 65,324 B and 1280 × 720. On another video the same name was only 320 × 240. It follows the upload's own frame shape, so it has to be measured rather than assumed.

"Do I need a different tool for a yt thumbnail downloader than for a grabber?"
No — the requests are the same. The difference is only what you do with the response: a grabber panel shows you the pictures, a downloader saves the bytes. Either way the file name you ask for is the decision that matters.

"If I fetch the same URL tomorrow, will I get a different picture?"
For the four videos measured here, no: 114 of 114 comparable requests came back byte-identical on two consecutive days, with no status changes. The header on those files allows two hours of caching, so a repeated fetch may be served from cache — but the content itself did not move.

"Why does a guide tell me to try hq720 if it is the same as maxresdefault?"
Because it is only sometimes the same. On two of the three videos compared here the two names were byte-identical; on the third they differed by 71,315 bytes at the same 1280 × 720 label. Asking for both and keeping the larger is the only rule that survives all three.

All numbers on this page were measured on 2 and 3 October 2026 by requesting each URL directly from img.youtube.com, recording the HTTP status, byte count, Content-Type, Cache-Control and Access-Control-Allow-Origin, hashing the response body, and reading the pixel dimensions out of each downloaded file's own JPEG or WebP header. The stability figure comes from comparing the two days' runs file by file; the two rows measured against a different host on the first day are excluded from that comparison and are why the count is 114 rather than 116. Videos are named by ID only; no titles, channels or links appear here, and none of the images are hosted on this site. Different videos return different numbers — that is the reason for measuring rather than listing.