YouTube Thumbnail URL: The Address, Part by Part
The address is the answer — there is no API call and no session behind it. It has three parts that matter and one that only looks like a choice. We tested the address directly on 14 October 2026: three slot names × eight endings = 24 requests, plus five hosts, four trailing decorations and eight path shapes. Only .jpg returned a picture. .jpeg, .png, .webp, .JPG in capitals, .gif, .bmp and no extension at all each returned 404 — every one of them with the same 1,097-byte JPEG body, byte-identical across all 25 misses in the run. And the host is genuinely free: img.youtube.com, i.ytimg.com, i9., i3. and i1. all returned the identical 65,324-byte file.
The address, in full
https://img.youtube.com/vi/<11-character video ID>/<slot name>.jpg
- Host — five interchangeable names, all serving the same bytes (table below).
/vi/— required. Dropping it returned404, and inserting an extra segment before the file name also returned404.- Video ID — exactly 11 characters of
A-Z a-z 0-9 _ -, matched literally. Wrong case is a miss, one character short or long is a miss. - Slot name — the only part that changes what you get. It names a slot, not a picture.
The extension is not a choice
Same video, same slot name (maxresdefault), eight different endings. Nothing here is a format conversion — every failure returns the same placeholder, and the placeholder is a JPEG no matter what you asked for.
| Ending asked for | Status | Bytes | Type served | Pixel size |
|---|---|---|---|---|
.jpg | 200 | 65,324 | image/jpeg | 1280 × 720 |
.jpeg | 404 | 1,097 | image/jpeg | 120 × 90 |
.png | 404 | 1,097 | image/jpeg | 120 × 90 |
.webp | 404 | 1,097 | image/jpeg | 120 × 90 |
.JPG (capitals) | 404 | 1,097 | image/jpeg | 120 × 90 |
.gif | 404 | 1,097 | image/jpeg | 120 × 90 |
.bmp | 404 | 1,097 | image/jpeg | 120 × 90 |
| no extension | 404 | 1,097 | image/jpeg | 120 × 90 |
So there is no .png URL for a YouTube thumbnail, and asking for one does not fail loudly — it hands you a 1,097-byte grey JPEG, cached for 30 seconds instead of the 7,200 a real file gets. If you need PNG, convert locally from the .jpg. The verification page shows how to spot the placeholder.
A search for a "YouTube thumbnail PNG" is worth answering directly, because the wording suggests a choice that is not there: the image host serves one set of files and every one of them is JPEG. A file whose address ends in .png is not a PNG — it is the 404 placeholder, and its own first four bytes say ff d8 ff e0, which is JPEG. The same is true of .webp on this host. Converting after download is the only route to another format, and it costs nothing in quality because there is no higher-quality source to lose.
The mirror question, a "YouTube thumbnail JPG", needs no hunting: it is simply the address as written. .jpg is the one ending the host answers with a picture, and the only one you ever need to type. When people ask whether the JPG is lower quality than a PNG they have in mind a format choice they are used to making when exporting — but here nothing is being exported. The server holds one file per slot, it is a JPEG, and asking for the same slot under any other ending returns the placeholder instead of a conversion.
The host is a real choice — and the only one that is
| Host | Status | Bytes | Pixel size |
|---|---|---|---|
img.youtube.com | 200 | 65,324 | 1280 × 720 |
i.ytimg.com | 200 | 65,324 | 1280 × 720 |
i9.ytimg.com | 200 | 65,324 | 1280 × 720 |
i3.ytimg.com | 200 | 65,324 | 1280 × 720 |
i1.ytimg.com | 200 | 65,324 | 1280 × 720 |
Five names, one file. That is why a URL copied out of a page sometimes points at i9.ytimg.com while another points at img.youtube.com — both are correct. The one difference that is real is the vi_webp path, which is the only way to get WebP: i.ytimg.com/vi_webp/<id>/maxresdefault.webp returned 200 / 28,620 bytes / image/webp for a picture that is 65,324 bytes as JPEG, about 56% smaller. Swapping the extension on the normal path does not get you there — that is the .webp row above.
The slot name is the only part that changes the picture
All of these are real addresses for one public video, measured on 2 October 2026 and again on 14 October 2026:
| Slot name in the URL | Pixel size | Bytes | What it is |
|---|---|---|---|
maxresdefault.jpg | 1280 × 720 | 65,324 | The big one — when it exists |
hq720.jpg | 1280 × 720 | 65,324 | Same bytes as maxresdefault on this video; not always |
sddefault.jpg | 640 × 480 | 31,029 | 4:3, not 16:9 |
hqdefault.jpg | 480 × 360 | 21,011 | The most reliable name of all |
mqdefault.jpg | 320 × 180 | 10,303 | True 16:9 |
default.jpg | 120 × 90 | 2,888 | The real small one |
oar2.jpg | 1920 × 1080 | 75,680 | Wider and heavier than maxresdefault here |
oar3.jpg | 1920 × 1080 | 76,507 | A different frame, not a copy of oar2 |
The number shortcut does not mean what people think
You will see short addresses like …/vi/<id>/0.jpg quoted as the way to get the biggest file. Measured on 14 October 2026, on three separate videos, 0.jpg was byte-for-byte identical to hqdefault.jpg — the 480 × 360 file, 21,011 bytes on the video above — and it was never the 1280 × 720 one. The numeric names are a shortcut family in their own right: 0.jpg → 480 × 360, and 1.jpg, 2.jpg, 3.jpg → 120 × 90 at 1,957, 2,025 and 2,188 bytes, three different still frames. If you want the big file, name it: maxresdefault.jpg.
Trailing decoration changes nothing — unless it is a space
Thumbnail addresses copied out of a live page often carry query strings. They are decoration, not identification:
?sqp=abcd1234&rs=AOn4CLfoo— 200, 65,324 bytes, same hash as the plain address?v=1— 200, same hash#t=1— 200, same hash- a trailing encoded space (
%20) — 404, 1,097 bytes
All four successful forms returned a byte-identical file (hash 22b4a49d…), so trimming a signed query string off a copied address is safe. What is not safe is stray whitespace — a space pasted onto the end of the URL is the one decoration that breaks it.
Two path shapes that always fail
Because the pattern is rigid, two plausible variations are worth knowing about. Removing the /vi/ segment (img.youtube.com/<id>/maxresdefault.jpg) returned 404, and inserting an extra segment (/vi/<id>/extra/maxresdefault.jpg) returned 404. Both gave the same 1,097-byte placeholder as everything else — the address grammar is not forgiving, it is just quiet about it.
Where the word "hd" lives — and where it does not
There is no hd.jpg and no hddefault.jpg in the address. The two names that carry a 1280 × 720 file are maxresdefault.jpg and hq720.jpg, and neither contains the word "hd" — hq stands for high quality, and 720 is the number that actually matters. On the one video where the two names disagreed, maxresdefault.jpg was 108,323 bytes at 1278 × 720 while hq720.jpg was 179,638 bytes at 1280 × 720 — so if you want the biggest file rather than the most familiar name, try both. The HD page has the counts.
So the honest answer to "what is the YouTube thumbnail HD address" is that there is no single one: it is maxresdefault.jpg or hq720.jpg, and which of the two is larger varies by video. Anything offering you an "HD" or "1080p" setting is choosing one of these slot names behind the scenes — and on the videos we measured, the 1280 × 720 slot is the highest that exists under the familiar names, with the 1920 × 1080 files living under oar2.jpg and oar3.jpg instead.
Questions people actually ask
"Can I get a thumbnail as a PNG?"
Not from the address. .png returned 404 with a 1,097-byte JPEG body. Download the .jpg and convert it locally — there is nothing to lose, since the served file is JPEG either way.
"Where is the HD thumbnail address?"
There is no separate HD file or HD setting. The two names that carry a 1280 × 720 picture are maxresdefault.jpg and hq720.jpg, and neither contains the letters "hd" — hq means high quality and 720 is the number that matters. Larger than 720p you would be looking at oar2.jpg / oar3.jpg.
"Is 0.jpg the highest resolution thumbnail?"
No. On three videos tested, 0.jpg was byte-identical to hqdefault.jpg at 480 × 360. The 1280 × 720 file is maxresdefault.jpg or hq720.jpg.
"Which host should the URL use?"
Any of them — img.youtube.com, i.ytimg.com, i9., i3. and i1. all returned the same 65,324 bytes. The only host distinction that changes anything is the vi_webp path, which is how you get WebP.
"My copied URL has a long query string. Do I need it?"
No. ?sqp=…&rs=…, ?v=1 and #t=1 all returned a file with the same hash as the plain address. Trim it.
"Why does my URL return a 404 but still show a picture?"
Because the body of that 404 is a valid 1,097-byte JPEG at 120 × 90. Nothing in the address told you the name was wrong; the status code did, and the picture did not.
The measurements on this page were taken on 14 October 2026 by requesting the addresses directly and reading each response's status, headers, byte length, first four bytes and pixel dimensions: three slot names × eight endings = 24 requests, five hosts, four trailing decorations, eight path shapes and four extra probes on a Short. The 0.jpg byte-identity claim was confirmed separately on three videos the same day, by comparing SHA-1 digests of 0.jpg and hqdefault.jpg. The slot-name byte figures come from the 2 October 2026 pass (4 videos × 26 names), and the WebP comparison from 11 October 2026. Every one of the 25 misses in the 14 October run was the same 1,097 bytes with the same digest and max-age=30. Videos are identified by ID only — no titles, channel names or watch links appear on this page, and no thumbnail is hosted here. A different video would move the byte counts, which is why every count is given with its video and date attached.