YouTube Thumbnail Downloader

The Hover Preview Is a Signed Animation, Not Your Thumbnail

Move the pointer over a video card and the still turns into a couple of seconds of moving picture. That moving picture is not the thumbnail, and it is not another size of the thumbnail. It is a separate animated WebP file at a different path on the same image host — /an_webp/<videoID>/mqdefault_6s.webp — and the server refuses to hand it over unless the address carries a signature the page issues. The still you probably came for sits at /vi/<videoID>/ and asks for no signature at all. Two files, two rules. Everything below was measured on 19 October 2026 against live YouTube image responses, and each figure is the status, byte count, content type, SHA-1 or pixel dimension we read back.

What you are looking atPath on the image hostFormatSignature required?Measured
the still thumbnail /vi/<videoID>/maxresdefault.jpg JPEG, 1280 × 720 no 200 · 65,324 B · 22b4a49df345
the hover preview /an_webp/<videoID>/mqdefault_6s.webp?du=…&sqp=…&rs=… animated WebP, 320 × 180 yes 200 · 228,984 B · 13aeee76e57a
Flat vector illustration: on the left a server shelf holding a stack of wide still picture frames with a play triangle; on the right a separate server holding a short filmstrip of narrow frames; between them a dashed line cut by a red cross
One host, two services: the stills on the left answer to a video ID, the filmstrip on the right answers only to a signature.

Three ways to fail, and they fail differently

We took real preview addresses out of live watch pages and then damaged them one property at a time. The important part is that the failures are not interchangeable — the server answers a missing signature with an image placeholder and a wrong signature with an HTML error page, which tells you where the check happens.

What was changedStatusBytesContent typeWhat came back
nothing — address used as published200228,984image/webpthe animation
query string removed404552image/webp120 × 90 grey placeholder, SHA-1 62302a6f7362
sqp only, du and rs removed4041,611text/htmlGoogle’s “Error 404 (Not Found)” page
last character of sqp changed4041,665text/htmlsame error page
last character of rs changed4041,665text/htmlsame error page
another video’s sqp + rs pasted in4041,665text/htmlsame error page — the signature is bound to this file
name swapped for hqdefault_6s.webp4041,665text/htmldoes not exist
name swapped for maxresdefault_6s.webp4041,669text/htmldoes not exist
name swapped for hq720_6s.webp4041,661text/htmldoes not exist
path /an_webp/ changed to /vi/4041,097image/jpegthe other grey placeholder, the 120 × 90 JPEG

Read the byte counts carefully, because they move for a boring reason: the HTML error page echoes the address you asked for, so a longer path makes a longer page. What stays fixed is the status and the content type. That is the tell to use: a miss on the .webp address without a signature returns 552 bytes of image/webp that a decoder will happily open as a 120 × 90 grey square, while a wrong signature returns about 1.6 KB of text/html. If you asked for an animation and your library reports “broken image”, one of those two happened and the file format in your hand says which.

Only one preview name exists

The _6s suffix looks like a member of the still ladder — maxresdefault, hq720, sddefault, hqdefault, mqdefault, default — and it is not. On the same signature, three other names were tried and all three returned 404 with the HTML page: hqdefault_6s.webp, hq720_6s.webp, maxresdefault_6s.webp. There is no high-resolution edition of the hover preview to fetch, and no ladder to climb. The 320 × 180 mqdefault_6s.webp is the whole set.

What is actually inside the animated file

We parsed the container rather than trusting a viewer: RIFF header, a VP8X chunk with the animation flag set, an ANIM chunk, then one ANMF frame per step. Five previews, five videos:

Video IDCanvasFramesTotal durationLoop fieldBytes
_JC3gDyH_YQ320 × 180243,000 ms0228,984
5pO-MTDW6nU320 × 180232,875 ms0151,512
HD3HXdioo8Y320 × 180172,125 ms0142,314
r4yvQN-10UM320 × 18024not recorded0201,034
dop4MTlf_zc320 × 18017not recorded0135,048

All five were 320 × 180 with the animation flag set and an alpha channel. The loop field was 0 in every file, which the WebP specification defines as “loop forever” — the preview is not a one-shot clip. And the du=3000 that rides along in every preview address is not the clip length: the durations above are 2,125, 2,875 and 3,000 ms on the same du=3000. What that parameter does and does not do is measured near the bottom of this page.

The still ladder does not care about signatures

Here is the part that surprises people who try to treat both paths the same. The same bogus signature that kills a preview does nothing to a still:

RequestStatusBytesSHA-1
/vi/<id>/maxresdefault.jpg20065,32422b4a49df345
/vi/<id>/maxresdefault.jpg?sqp=bogus&rs=bogus20065,32422b4a49df345
/vi/<id>/maxresdefault.jpg?sqp=20065,32422b4a49df345
/vi/<id>/hq720.jpg?sqp=bogus&rs=bogus20065,32422b4a49df345

Byte-identical, four times over, and identical to the request with no query string at all. So the signature gate sits on the /an_webp/ service only. Whatever sqp means on a thumbnail address — tracking, cache key, decoration — it is not an access check, and stripping it changes nothing you can measure here. (The last row is a separate quirk of this particular video: its hq720.jpg and maxresdefault.jpg are the same file, byte for byte. It is not always true — see the table below.)

The preview is heavier than the small still, not heavier than the big one

An intuitive guess is “animation must be the biggest file”. Measured against the 1280 × 720 still, that guess fails half the time. Measured against the 320 × 180 still, it is true by a wide margin.

Video IDPreview320 × 180 stillpreview ÷ small still1280 × 720 stillpreview ÷ big still
r4yvQN-10UM201,03415,66412.8×256,5500.78×
xOXolSQcEb4128,53013,4099.6×210,4110.61×
Y-rmzh0PI3c144,25811,05913.0×121,5671.19×
JpuX5uQdIqg126,58016,3657.7×346,2230.37×
dop4MTlf_zc135,04819,3427.0×94,3601.43×

So: 7.0× to 13.0× the bytes of the still at the same 320 × 180 size, but anywhere from 0.37× to 1.43× the 1280 × 720 file. If you are on a metered connection and your goal is the sharpest picture of the video, the animation is not a shortcut to it — three of these five previews are smaller than the big still, and every one of them is the wrong shape for a 16:9 poster.

The first frame is not the thumbnail on the card

Another reasonable guess: the animation starts from the still you just saw, so you could grab frame one and be done. We decoded each animation and compared its first frame, pixel by pixel, with the video’s mqdefault.jpg — both are 320 × 180, so no scaling was involved. On a 0–255 mean-absolute-difference scale, five videos scored 11.2, 36.7, 48.5, 51.4 and 81.0. Those are not re-compression artefacts; they are different pictures. The thumbnail is usually a designed image or a chosen moment, and the preview is footage from somewhere else in the video. Taking frame one gives you a frame of video, not the card art.

Why nobody can hand you a preview by video ID

The obvious next idea is “fine, I will build the address myself”. You cannot, and the reason is worth stating precisely: the signature is issued per request by the page that is showing the card, and the page you are on does not publish it for its own video. We read two live watch pages and counted the preview addresses inside the HTML: 16 on one, 18 on the other, all unique — and neither page contained a preview address for the video being watched. They were previews of the recommendation cards around it.

That is also why this tool fetches stills only. A thumbnail address is derivable from an 11-character ID and returns the same bytes for anyone; a preview address is not derivable and is issued with a signature tied to the file it names — reuse another video’s and you get the HTML 404, as measured above. Presenting a “preview downloader” that just strips the query string would produce the 552-byte grey square every single time, so we do not offer one.

About that du number

We tried to find out what du controls, and the honest answer is: not the file. With the signature held constant on one video, du=0, 2999, 3000 and 6000 all returned 200 and byte-identical content — 151,512 bytes, SHA-1 73bd3bfa64f9. If du were a duration or a quality selector, those four numbers would not hand back the same file. du=1 returned 403 both times we tried it, so the value is validated somewhere, but we could not establish a rule beyond “very small values are refused”. One more caveat in the same spirit: a rapid sweep of a dozen du values produced 403s on several values that succeeded when re-tested with three seconds between requests, so part of that pattern was our own request rate and not the parameter. We are not going to publish a theory of du that our own second run contradicts.

What to do with this

Questions people actually ask

“Is the hover preview just a smaller version of the thumbnail?”
No. It is a different picture at a different address, served as animated WebP rather than JPEG, with 13–24 frames and a 2.1–3.0 second run time in the five files we parsed. Comparing the animation’s first frame with the still on the same card gave a mean pixel difference of 11.2 to 81.0 out of 255 — different images, not a resized one.

“Why does the preview URL give me a grey image instead of an error?”
Because a miss on a .webp address returns 404 with a real 552-byte WebP file, 120 × 90, that decodes perfectly. Your browser shows the grey square and no error. Drop the whole query string and you get exactly that, three videos out of three, with the same SHA-1 62302a6f7362 each time.

“Can I edit a working preview link for another video?”
No. Swapping in one video’s sqp and rs on another video’s path returned 404 and Google’s HTML error page, not the animation — the signature names the file it was issued for. Changing one character of either value gave the same result.

“Is there a 720p or 1080p version of the preview?”
Not at any name we could reach. hqdefault_6s.webp, hq720_6s.webp and maxresdefault_6s.webp all returned 404 even with a valid signature attached. Every preview we parsed was a 320 × 180 canvas.

“Does a signature help on a normal thumbnail URL?”
It changes nothing measurable. maxresdefault.jpg with no query, with ?sqp=bogus&rs=bogus, and with an empty ?sqp= returned the same 65,324 bytes and the same SHA-1. Thumbnails are open; only the animation is gated.

Every figure on this page comes from requests we made ourselves on 19 October 2026: five preview files parsed at the container level, three of them also measured for total duration, five still ladders measured for byte count, 37 damaged addresses across three videos, two live watch pages read for preview addresses, and a repeated du probe spaced three seconds apart. Video IDs are given as IDs and no title, channel name or image from any video is reproduced here. Two things we did not establish and therefore do not state: what du is for, beyond the fact that it does not change the bytes; and whether a preview exists for every video, since we only tested the ones live pages were handing out that day. Nothing on this page is an estimate.