YouTube Thumbnail Downloader

YouTube Thumbnail Resize: What Resizing Can and Cannot Do

Resizing is two different jobs wearing one word. The first is fetching the size that already exists, and it costs nothing. The second is inventing pixels that were never there, and no resizer on earth can do it — it can only guess. The reason this matters is that the two produce a file that looks the same in a preview. In our measurements (2, 5 and 11 October 2026, 24 public videos) the ladder tops out at 1280 × 720, so any "bigger" thumbnail is a guess: taking 480 × 360 up to 1280 × 720 multiplies the pixel count by 5.33 and adds exactly zero information. Before you resize anything, spend ten seconds checking whether the size you want is simply sitting there under another name.

The order that saves you the resize entirely

Every video has its own set of files, and the biggest one is not always the one people ask for first. Ask in this order and stop at the first address that does not return the 1,097-byte miss:

1. maxresdefault.jpg — 1280 × 720 when it exists (10 of 12 videos in our 5 October sample)
2. hq720.jpg — also 1280 × 720, and not always the same file: on one video it was 179,638 bytes where maxresdefault.jpg was 108,323 bytes at 1278 × 720
3. oar2.jpg / oar3.jpg — the odd ones. These returned 1920 × 1080 on one video and 320 × 240 on another, and in 10 of 12 Shorts they were larger than maxresdefault.jpg
4. sddefault.jpg — 640 × 480, but 4:3, so read the next section before using it
5. hqdefault.jpg — 480 × 360, the only name that answered on 12 of 12 videos
6. mqdefault.jpg (320 × 180) then default.jpg (120 × 90)

If step 1 or 2 gives you 1280 × 720, you are done. Resizing only starts when every name above has been tried and the best you have is smaller than what you need — which does happen: one video in our 5 October sample had neither 1280 × 720 nor 640 × 480 and topped out at 480 × 360 at 23,549 bytes. The size page lists the whole ladder with the byte range each rung actually covered.

What upscaling actually buys you: measured

Here is the same video's picture at three rungs of the ladder. The pixel counts are exact; the byte counts are from the actual files.

Going from 480 × 360 to 1280 × 720 is 5.33× the pixels for about 3.1× the bytes — and that 3.1× is the server encoding a real 1280-pixel-wide frame, not guessing one. Do the same move in a resizer and you get 5.33× the pixels for whatever the file costs, with every extra pixel interpolated from neighbours. At small display sizes you will not see the difference. At full size you will see exactly one thing: softness.

The trap: resizing the miss

A missing name does not return an error. It returns 1,097 bytes at 120 × 90 — a plain grey JPEG that opens in any viewer and looks like a legitimately small thumbnail. Upscale it to 1280 × 720 and you get a smooth, clean, perfectly valid 1280 × 720 grey rectangle. Nothing about the resized file says anything went wrong, because nothing did: you resized a real image that happens to be a placeholder. Check the byte count before you resize, not after — 1,097 is exact and identical on every miss we have ever captured, while the smallest real file in the same runs was 2,888 bytes at the very same 120 × 90 size. The verification page has that check in full.

Resizing across shapes: 16:9, 4:3 and 9:16 are not the same rectangle

Half of what people call "resize" is really a shape change, and a shape change has three honest options — none of which is stretching.

• 1280 × 720 is 16:9. So is 320 × 180 and 480 × 360. Shrinking between these loses nothing but detail.
• 640 × 480 is 4:3. That is sddefault.jpg. Scaling it to 1280 × 720 stretches it, because 640 × 480 and 1280 × 720 are not the same proportions. Cropping it to 16:9 gives 640 × 360 — fewer vertical pixels than the 480 × 360 file you could have taken instead.
• 1080 × 1920 is 9:16 — a Short. You cannot resize a 1280 × 720 landscape file into that shape without inventing the sides. The upright file usually exists already: oar1.jpg, oar2.jpg and oar3.jpg were 1080 × 1920 on 12 of 12 Shorts we measured.

So the shape rule is: look for the file that is already the shape you want before you touch a crop or a pad. If you must pad, pad — a black or blurred bar is honest, a stretched face is not.

Resizing down: the one direction that is free

Shrinking a real 1280 × 720 file to 480 × 360 or 320 × 180 throws away detail, and that is the good case: nothing is invented, and the result is what a smaller rung would have been anyway. This is the only resizing worth doing by hand, and even then the server has usually done it for you already — the ladder in the table above is the same picture at five sizes. Our largest measured file in any run was 184,051 bytes, comfortably inside the platform's stated limit for an uploaded thumbnail, which is measured in megabytes — so shrinking for file size is not the problem this word usually describes.

How to tell afterwards which one you did

1. Check the byte count first. 1,097 means the miss; a real file in these runs started at 2,888 bytes at 120 × 90.
2. Check the pixel size in the file's own header, not the file name — maxresdefault.jpg came back 1278 × 720 on one video, so the name does not pin the width.
3. If you upscaled, keep the original. You can always re-derive a small file from a big one; you can never re-derive a big one from a small one.

Questions people actually ask

"How do I make a thumbnail bigger without losing quality?"
By not resizing it. Fetch the biggest file that exists for that video — usually maxresdefault.jpg or hq720.jpg at 1280 × 720 — because there is no larger file to lose quality against. Above 1280 × 720 you are not resizing, you are reconstructing, and the reconstruction is a guess.

"My thumbnail is blurry after I enlarged it. Is the resizer bad?"
The resizer is fine; the input was small. 480 × 360 to 1280 × 720 is 5.33× the pixels. If the 1280 × 720 file exists for that video, using it instead costs one more request and gives you a genuinely sharp frame.

"Can I resize a thumbnail to 1080 × 1920 for a Short?"
You can pad or crop one to that shape, but the upright file usually already exists — oar1/oar2/oar3.jpg were 1080 × 1920 on all 12 Shorts we checked. Start there and you have nothing to invent; the Shorts page has the counts name by name.

"Is sddefault.jpg a good source for resizing up?"
It is 640 × 480, which is 4:3 — so a 16:9 target means cropping, and cropping leaves 640 × 360. That is wider than hqdefault.jpg's 480 × 360, but you paid for the extra width by discarding 120 rows of picture, top and bottom. Use it when the subject sits in the middle of the frame; use hqdefault.jpg when you cannot afford to lose the edges.

"Do I need to resize to stay under a file-size limit?"
Almost certainly not. Our largest measured thumbnail file was 184,051 bytes, and the smallest 2,888 — the whole ladder lives in the low hundreds of kilobytes, well under the platform's stated limit for an uploaded thumbnail.

Every number on this page was measured by requesting img.youtube.com/vi/<id>/<name> directly and reading each returned file's own JPEG header for width and height and its Content-Length for bytes. Sources: 2 October 2026 — 4 public videos × 26 names (124 requests), which supplied the byte columns above; 5 October 2026 — 12 public videos, which supplied the hit counts and the 480 × 360 top-out case; 11 October 2026 — 8 videos × 5 names plus 11 follow-up requests; 12 October 2026 — 12 Shorts × 12 names, which supplied the 1080 × 1920 counts. The 1,097-byte miss figure is exact and identical on every miss in every pass. Pixel-count ratios are arithmetic on the sizes stated. 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 sample of videos would move the counts, which is why every count is given with its sample size attached.