Why your thumbnail looks blurry

What the viewer actually downloads

This is measurable, so here it is measured. I loaded a real watch page and a real search results page, pulled the thumbnail URLs out of the markup and fetched them. Every one of them came back as WebP, cropped to 16:9, sized to the slot it was going into:

The delivered sizes match the rendered slots exactly — 168 × 94 is the suggested item I measured in the interface, and 336 × 188 is that same slot on a Retina screen. YouTube is not sending you a scaled-down copy of a big image; it is sending a file built for that box.

Two numbers do most of the work

The first is the slot. A suggested item is 168 CSS pixels wide, and on the 2× screen almost everyone has, that is 336 device pixels. Your 1280-pixel-wide design is being delivered as a 336-pixel-wide picture. Every judgement about sharpness has to be made there, not in your editor.

The second is the byte budget. That 336 × 188 file is 17.6 KB, which is 0.28 bytes per pixel — a real compression ratio, not a nominal one. It is enough for a clean picture with few elements and not enough for a busy one, and that is the entire mechanism behind most complaints about YouTube “ruining” a thumbnail.

1280 × 720 is a master, not a delivery format

Uploading at 1280 × 720 is still right, because everything above is derived from it and a derivative cannot be sharper than its source. But it is worth being clear about what happens to it: across eleven real videos the stored maxresdefault.jpg ranged from 114 KB to 318 KB, averaging 188 KB. Whatever you uploaded, that is what YouTube kept.

And there is exactly one place that full-size file is delivered to a human: a link preview. The watch page's og:image points at maxresdefault.jpg, so a link pasted into a chat app or a Slack channel shows the 1280 × 720 JPEG. Inside YouTube itself, nothing does. The upload spec that master is measured against is on YouTube's custom thumbnail page.

Cause 1: you are judging it at the wrong size

This is the most common cause by a wide margin, and it is not really a quality problem — it is a viewing problem. A thumbnail examined at 100% in a design tool is being examined at roughly four times the size any viewer will ever see, and a design that only holds up at that size will read as soft everywhere else.

The inverse is also true and more useful: a design that survives a 336-pixel box looks *deliberate* at full size. So check at the small size first and treat the large one as a bonus. It is one of the seven habits in the guide on common mistakes, and it is the one that changes the most for the least work.

Cause 2: the source was never sharp

Three versions of this, all of which survive into every derivative:

An upscaled source. A 640-pixel-wide image stretched to 1280 has no more detail than it started with, but it does have more pixels for the encoder to spend bytes on. You get the file size of a big image and the detail of a small one.

A re-encoded JPEG. Exporting a JPEG, opening it, editing it and exporting it again compounds the artefacts, and YouTube then re-encodes that. Keep the working file lossless and export once.

A frame grab as the base layer. A still pulled from your own video is already compressed by the video codec, at a bitrate spread over thirty frames a second. It is the softest possible starting point for something that will be compressed again.

Cause 3: grain spends the byte budget

This one is worth measuring rather than asserting, so I did. Same photograph, three versions — clean, plus grain at ±12 levels, plus a smooth diagonal gradient across 40 levels — each scaled to the 336 × 188 slot and encoded to hit the 17.6 KB the real file uses.

The clean version reached that budget at quality 0.95. The grainy one only afforded quality 0.80. Turned around: at a fixed quality of 0.80, the clean file is 9.4 KB and the grainy one 17.5 KB — 86% more bytes for the same picture. The gradient cost nothing at all, 9.4 KB, which is the useful surprise here.

So the folk wisdom is half right. Gradients and soft light are cheap; film grain, sensor noise, texture overlays and heavy dithering are expensive, and at a fixed budget the encoder pays for them by throwing away detail somewhere you did care about. Chrome's encoder is not YouTube's, so treat the exact numbers as an order of magnitude — the direction is not in doubt.

Cause 4: the letterboxed variants

Two of the static files are 4:3, which is a leftover from when YouTube was, and they do not crop your image — they pad it. hqdefault.jpg is 480 × 360 with 45 pixels of black at the top and bottom, so the actual picture is 480 × 270. sddefault.jpg is 640 × 480 with 60-pixel bars, giving 640 × 360.

That matters because those URLs are what a lot of things outside YouTube reach for, and because of the fallback: on a video with no maxresdefault — an older or lower-resolution upload — the og:image becomes a resized hqdefault instead. I verified this on a 2005 upload: 480 × 360, 21 KB, bars included. If your link previews look letterboxed and soft, that is why, and the fix is having a maxres-eligible upload.

The file size cap is not a quality budget

YouTube's custom thumbnail limit is 50 MB from a computer and 2 MB from the phone, and the 2 MB is one of the more misread numbers in the whole workflow — it is the mobile figure, quoted everywhere as though it were the only one. It is a ceiling on what you may send, not an indication of what will be delivered: the files above are between 7 KB and 318 KB. Filling the allowance does nothing except give the encoder more of your file to discard.

What does matter is arriving under the cap without a second round of compression. A 3 MB export squeezed down to 1.9 MB in an online compressor is a JPEG that has been encoded twice before YouTube encodes it a third time. Export once, at the size and format in the size and specs guide, and let the platform do its own reduction.

What actually reads at 336 pixels

Past a point, sharpness at that size is a composition property rather than an export property. Fewer elements, each larger, is the whole technique, and the reason is the byte budget: detail spent on three small things is detail not spent on one big thing.

The three specific floors are each measured in their own guide. Text has a minimum height that survives the reduction — see the guide on text size. A face has to fill about a third of the frame, and over half for the suggested column, which is the guide on faces. And separation between adjacent areas has to come from luminance and not only hue, which is the guide on colour. All three are the same argument arriving from different directions.

What to export

1. 1280 × 720, 16:9, sRGBThat is the master YouTube keeps as maxresdefault, and the aspect ratio every delivered crop is built on. Larger than 1280 buys nothing; smaller than 1280 costs you the maxres variant and the link-preview quality with it.
2. One export, not twoGo straight from your lossless working file to the file you upload. Every intermediate JPEG is a round of artefacts that the platform's own encoder will then amplify rather than clean up.
3. Under the limit without a compressorA high-quality export at full resolution lands far under the 50 MB you get from a computer, so nothing has to be squeezed to fit. If yours comes out unexpectedly heavy, the design has more noise or texture in it than the format wants — reduce that rather than running the file through a second compressor.
4. Check it at 336 pixels before you uploadThe last step is the only one that tells you whether the previous three mattered. Look at it in the slot, not in the editor.

The one-minute check

Everything above converges on the same thing: judge the file where it will be delivered. That is a viewing problem, and a viewing problem is easy to fix — you just need the real sizes side by side, with real competitors around them so you are comparing rather than admiring.

That is what the preview tool does. If your thumbnail holds together in the suggested column, at the smallest and most compressed size YouTube ships, then the sharpness of your export was never the problem — and if it does not, no export setting will save it.

The questions everyone asks