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 at | Path on the image host | Format | Signature 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 |
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 changed | Status | Bytes | Content type | What came back |
|---|---|---|---|---|
| nothing — address used as published | 200 | 228,984 | image/webp | the animation |
| query string removed | 404 | 552 | image/webp | 120 × 90 grey placeholder, SHA-1 62302a6f7362 |
sqp only, du and rs removed | 404 | 1,611 | text/html | Google’s “Error 404 (Not Found)” page |
last character of sqp changed | 404 | 1,665 | text/html | same error page |
last character of rs changed | 404 | 1,665 | text/html | same error page |
another video’s sqp + rs pasted in | 404 | 1,665 | text/html | same error page — the signature is bound to this file |
name swapped for hqdefault_6s.webp | 404 | 1,665 | text/html | does not exist |
name swapped for maxresdefault_6s.webp | 404 | 1,669 | text/html | does not exist |
name swapped for hq720_6s.webp | 404 | 1,661 | text/html | does not exist |
path /an_webp/ changed to /vi/ | 404 | 1,097 | image/jpeg | the 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 ID | Canvas | Frames | Total duration | Loop field | Bytes |
|---|---|---|---|---|---|
_JC3gDyH_YQ | 320 × 180 | 24 | 3,000 ms | 0 | 228,984 |
5pO-MTDW6nU | 320 × 180 | 23 | 2,875 ms | 0 | 151,512 |
HD3HXdioo8Y | 320 × 180 | 17 | 2,125 ms | 0 | 142,314 |
r4yvQN-10UM | 320 × 180 | 24 | not recorded | 0 | 201,034 |
dop4MTlf_zc | 320 × 180 | 17 | not recorded | 0 | 135,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:
| Request | Status | Bytes | SHA-1 |
|---|---|---|---|
/vi/<id>/maxresdefault.jpg | 200 | 65,324 | 22b4a49df345 |
/vi/<id>/maxresdefault.jpg?sqp=bogus&rs=bogus | 200 | 65,324 | 22b4a49df345 |
/vi/<id>/maxresdefault.jpg?sqp= | 200 | 65,324 | 22b4a49df345 |
/vi/<id>/hq720.jpg?sqp=bogus&rs=bogus | 200 | 65,324 | 22b4a49df345 |
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 ID | Preview | 320 × 180 still | preview ÷ small still | 1280 × 720 still | preview ÷ big still |
|---|---|---|---|---|---|
r4yvQN-10UM | 201,034 | 15,664 | 12.8× | 256,550 | 0.78× |
xOXolSQcEb4 | 128,530 | 13,409 | 9.6× | 210,411 | 0.61× |
Y-rmzh0PI3c | 144,258 | 11,059 | 13.0× | 121,567 | 1.19× |
JpuX5uQdIqg | 126,580 | 16,365 | 7.7× | 346,223 | 0.37× |
dop4MTlf_zc | 135,048 | 19,342 | 7.0× | 94,360 | 1.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
- If you want the picture from the card: use the video ID and the still ladder —
/vi/<videoID>/maxresdefault.jpgand its neighbours. No signature, same bytes for everybody. The link-shape page lists the address forms that work and the two that never will. - If your copy of a still refuses to update: that is a cache lifetime question, not a file question — the cache page measures the two hours and the one tag that covers six sizes.
- If you downloaded something and got a grey square: check the byte count before blaming the site. 552 bytes means a
.webpaddress was missed; 1,097 bytes means a.jpgaddress was missed — both are valid image files, which is why browsers show a picture instead of an error. The verification page has the full fingerprint table. - If you wanted motion: screen-record the card, or ask the uploader. There is no supported way to request the animation by ID, and this tool deliberately does not pretend otherwise. The mobile page covers what long-press actually saves on a phone, which is the still, not the motion.
- If you are checking what a channel keeps where: the channel art page separates the avatar and banner slots from the video slots, which are on a different host entirely.
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.