YouTube Thumbnail Downloader

A Private Video's Thumbnail Is Not Withheld: It Is the Same 1,097 Bytes as a Typo

Every downloader FAQ says the same sentence — "only public videos" — and none of them shows what "no" actually looks like. We checked, on a video we uploaded ourselves and saved as private on 24 October 2026. The answer is not a refusal and not a blurred picture: it is the ordinary grey 120 × 90 placeholder, 1,097 bytes, with the same SHA-1 as the response for a video ID that has never existed. Ten file names, three image hosts, and the signed URL copied out of the private video's own page all returned that one file. So a downloader pointed at a private video cannot tell you it is private — it can only tell you it found nothing, which is the same thing it says when you mistype an ID.

What we did, so you can repeat it

Four steps, in this order. Nothing on this page is inferred from how we think YouTube behaves.

• Uploaded a 5-second 1280 × 720 file to our own channel and saved it with visibility set to private; Studio's own status line confirmed the save. The resulting video ID is 9jEIbfAUtSw.
• Confirmed the state from outside Studio: anonymous oEmbed for that ID answers 403, where the public video on the same channel answers 200. That is the difference we can independently verify.
• Requested ten file names against the image host — maxresdefault, hq720, sddefault, hqdefault, mqdefault, default, maxres1, maxres2, maxres3, plus the .webp path — with no cookies and no Referer.
• Repeated the same requests on img.youtube.com and i9.ytimg.com, and once more using the ?sqp= signed URL taken from the private video's own watch page.

The private video, file by file

Ten names. One answer. The byte count never varies and neither does the hash, which is the part that matters: a real JPEG of the same nominal size would not be 1,097 bytes.

The WebP miss is a different file from the JPEG miss — 552 bytes instead of 1,097 — which is the second placeholder documented on the mobile page. Both are the same squares we get when a size simply does not exist. Nothing about the private state produces a third, special response.

A private ID and an invented ID are the same file

This is the comparison that decides what a downloader can honestly say. We requested the same names for ZZZZZZZZZZZ, an 11-character ID that has never been used by anyone.

Identical status, identical length, identical hash. There is no header, no error body and no image difference that separates "this video exists but is private" from "this ID is nonsense". If a tool tells you a private video's thumbnail "could not be found", that statement is true but it carries no more information than telling you your typing was wrong. If a tool claims it did fetch one, look at what it hands back: at 1,097 bytes and 120 × 90 it is the placeholder, and the size test on the verification page will catch it.

The signed link does not help either

YouTube signs thumbnail addresses with sqp (and sometimes rs) tokens. It is reasonable to assume a signature issued for a private video would carry permission. It does not.

So the three hosts that normally return identical bytes stay identical here too — identically empty. A signature proves the URL was generated by YouTube; it does not grant access to the file behind it.

The private video's page still names the file — that is the trap

Here is the part that catches scraper builders. The watch page for the private video, fetched anonymously, still contains the thumbnail address in its HTML:

i.ytimg.com/vi/9jEIbfAUtSw/hqdefault.jpg — two occurrences in an 862,612-byte document.

For comparison, the public video's page (1,229,048 bytes) contains 110 ytimg.com references, mostly signed hqdefault addresses for the recommendation rail. So the address is written down on both pages, and on one of them it points at nothing. A scraper that extracts the first i.ytimg.com match will therefore "succeed" on a private video and save a grey square — and because that square is a valid 120 × 90 JPEG, nothing in the save step will complain.

What the same channel's public video returns

One variable changed: publication state. Same channel, same host, same request shape.

Two things in that table are worth keeping. The public video's maxresdefault and hq720 are byte-identical — 106,809 both, one hash — which is the alias case measured on the maxres variants page. And default.jpg is also 120 × 90, the same pixel size as the placeholder, at 2,263 bytes. Pixel dimensions alone do not tell you whether you are holding a real thumbnail; the byte count does.

An unfinished upload behaves the same way

Before the video was saved, while Studio still listed it as a draft, the same ten requests returned the same 404 and the same 1,097 bytes. A draft has an upload URL and even a video ID, and the image host treats it exactly like a private video — because at that point there is no published thumbnail to serve. If you are testing a downloader against your own brand-new upload and it "cannot find" the thumbnail, this is why: wait until it is published.

What the three biggest pages actually say

We saved both competitor sitemaps in full and vidiq's thumbnail category, then stripped scripts and styles: 23 HTML files, 21 article pages plus two copies of the category listing, 35,817 words. Counts for the whole corpus:

The three FAQs, quoted as written: "Can you download thumbnails from private videos? No, we only support public videos." · "Can I get thumbnail of private videos? No, only public videos possible." · "Is it possible to getting a Thumbnail preview of private videos? No, it only works for public videos." All three are correct. None of them says what the server returns, so none of them can help you tell a private video from a typo, and none of them tells you that the video's own page will still hand you a URL.

What we did not measure

• Unlisted — measured two days later, and it does not behave like private. On the same video ID, switched to unlisted on 26 October, all ten names returned 200 with real files up to 53,498 bytes. So the answer to "is the picture withheld" depends on which non-public state you mean. The numbers are on the unlisted page.
• Private videos owned by other channels. We measured one private video, ours. A channel-level or region-level difference is possible and untested.
• Age-restricted and members-only videos. Not tested at all; the pages that mention them mention them in a different context (A/B testing eligibility).
• Whether the cache changes anything. A private video has no published thumbnail to cache, so the question did not arise here; the cache behaviour for public thumbnails is on its own page.

Questions people actually ask

"So can I download the thumbnail of a private video?"
Not from the image host, and not with any downloader that relies on it — the files are not served. The only place the picture is visible is where the owner can see it, inside their own video's settings; that is an owner-only path, not something a public tool can do for you.

"But I found a URL for it. Why does it not work?"
Because the address exists as text and the file does not exist as a resource. The private video's own page printed i.ytimg.com/vi/9jEIbfAUtSw/hqdefault.jpg twice, and requesting that exact address returned 404 with 1,097 bytes.

"Does it help to sign the request?"
No. The signed ?sqp= URL lifted from the page returned the same 404 and the same 1,097 bytes.

"How do I know I am looking at the placeholder and not a small thumbnail?"
Two checks, both cheap: the byte count (a miss is 1,097 on the .jpg path, 552 on .webp) and the pixel count of the decoded file (120 × 90). A real default.jpg is also 120 × 90 but weighs 2,263 bytes, so use the byte count, not the dimensions.

"Will it work once the video is published?"
Yes, and immediately in our test: the same channel's published video answered 200 with real files on every rung of the ladder, up to 106,809 bytes at 1280 × 720.

Everything above was measured on 24 October 2026: one video uploaded and saved as private (9jEIbfAUtSw), ten file names requested on three image hosts, one signed URL replayed, one invented ID used as a control, and one published video on the same channel for contrast. The corpus counts come from re-fetching both competitor sitemaps and vidiq's category page on the same day; all three were byte-identical to the previous day's copies. We name no other channel and show no thumbnail image. The one state we could not set — unlisted — is listed above as unmeasured rather than described. Nothing here is an estimate.