Why maxresdefault is missing for some videos

Paste a link into the thumbnail downloader and, for some videos, the largest card reads "not available for this video". That is not the tool failing: it is the tool declining to hand you a gray 120×90 placeholder as if it were a 1280×720 image. This guide explains what YouTube sends back for a size it never generated, why a plain image tag makes that look like a thumbnail, how the downloader tells the two apart, where the check stops, and what you get instead. Every figure and verdict below is computed at build time by the functions that run when you use the tool.

5 sizes, 2 of them optional

From a video ID, YouTube's image server stores 5 thumbnail sizes at predictable addresses. The first 3 exist for effectively every public video; the other 2 — sddefault and maxresdefault — are generated only for some uploads. For the example ID jNQXAC9IVRw, the engine derives this set:

Each key maps to one URL; the largest is https://img.youtube.com/vi/jNQXAC9IVRw/maxresdefault.jpg, and the set ends there — maxresdefault at 1280×720 is the largest size YouTube serves back out. Note the frames: only mqdefault and maxresdefault are 16:9; the rest, including sddefault, reduce to 4:3, which the aspect engine files under "Older video; sddefault storage frame". What each size is for is covered in the sizes guide; the upload-side rules are cited to Google's help documentation on the size guide.

"Only for some uploads" is the whole of what this site can say about which videos get the optional sizes. It is what the methodology page states. This guide does not speculate about YouTube's reasons, and neither does the tool: it reports what the image server served for the video you pasted, at the moment you checked.

What YouTube sends back for a size it never generated

When a size is missing, YouTube answers with HTTP 404. The unusual part is the response body: instead of an error page, it is a real, decodable image — a gray placeholder measuring 120×90 pixels. Its frame is 4:3, the shape of the smallest stored size, not the 16:9 of the maxresdefault that was asked for.

A plain <img> tag does not consult status codes; it decodes whatever bytes arrive, and these decode fine. A page that writes the maxresdefault URL into an image tag shows a gray rectangle — and, if stretched to a 1280-pixel-wide slot, turns 120 pixels of gray into a large, blurry one. A page that wires a download button straight to that URL saves the placeholder to your disk under a "maximum resolution" filename. Nothing in that chain asked whether the image was the thumbnail. That is the junk download the methodology page warns about.

The two-signal check

The downloader fetches each of the 5 URLs in your browser and records two things per size: whether the response reported success, and the pixel dimensions the bytes decode to (or that they did not decode). A failed status is reported missing at once, before any decoding. When the status is a success, the decoded dimensions go to a pure function, classifyThumbnail, together with the size requested. The function carries the status rule as well, first in its list, so the verdict is the same whichever signals a caller supplies. Three rules and a default, in order:

1. If the response was not a success, the size is missing.
2. If the bytes produced no dimensions, the size is undecodable.
3. If the decoded width is smaller than the width requested and no wider than the placeholder (120 px), the size is missing — a placeholder body arrived, whatever the status said.
4. Otherwise the size is available.

Here is that function run against probe inputs at build time. Each verdict is the engine's own output, not a typed-in expectation:

Three rows matter most. The first is the everyday case: the 404 alone settles it as "missing" before any decoding happens. The second is the belt-and-braces case: a placeholder-sized body arriving with a success status, which the width rule still catches as "missing". And the default row shows why the rule is a comparison rather than a fixed threshold: default genuinely is 120×90, so a 120-pixel decode is exactly what was requested and the verdict is "available". Without the "smaller than requested" half of the rule, the smallest real thumbnail would be reported missing on every video.

Where the check stops

The last row is the honest limit. A decode of 640 pixels where 1280 was requested is narrower than nominal but far wider than the placeholder, so the verdict is "available". The rule is deliberately a placeholder check, not a resolution audit: it catches the one specific junk response YouTube is known to send and does not second-guess a real image that is smaller than the key's nominal size.

The check also cannot tell you why. A "missing" verdict means the image server did not serve that size for this video when you asked — not that the upload was of any particular quality, age, or type, about which this site has no information. The "undecodable" verdict is different again: a success status arrived, but the bytes did not decode in your browser. The card then reports that the size could not be decoded, and draws no preview or button for it. And the tool only reports what YouTube currently serves: if nothing usable comes back for any of the 5 sizes, every card is unavailable, and that is the correct report, not a guess.

What the downloader shows instead

Each size gets a card headed with its label and nominal dimensions. A size that passed the check gets a preview at true proportions and a "Download JPG" button whose file is the real bytes your browser fetched, named descriptively — for the example ID and maxresdefault, youtube-jNQXAC9IVRw-maxresdefault-1280x720.jpg. A size classified "missing" gets no preview and no button; its card reads "Not available for this video — YouTube generates this size only for some uploads." The status line above the cards sums the run: for a video where only the 3 guaranteed sizes were generated, the engine classifies 3 of 5 sizes available and 2 not generated by YouTube for this video, and the largest card with a button is hqdefault at 480×360.

That is the whole difference between this tool and one that renders junk: the classification happens before a button is drawn, on decoded pixels rather than on the URL. The placeholder never becomes a download because it never becomes "available".

When downloads are blocked: the "Open image" fallback

Reading image bytes from another domain requires that domain's permission (CORS). YouTube's image server sends Access-Control-Allow-Origin: * on thumbnail responses — verified empirically, and documented on the methodology page — which is why your browser can fetch the file, decode it, classify it, and offer a one-click download without this site's servers ever seeing your link. The mechanism has its own guide, how the one-click download works.

Some environments break that path: an aggressive extension, or a corporate proxy that strips CORS headers. When the fetch itself fails, the downloader falls back to loading each URL in an <img> element and reading the decoded natural width — the second signal doing the work alone, through the same classifyThumbnail function with the status treated as a success. The placeholder is still caught: a 120-pixel decode against a 1280-pixel request is still "missing". Sizes that pass show an "Open image" link to the original YouTube URL with a save instruction ("Right-click the opened image → Save image as…"), and the status line says direct downloads were blocked in this browser. What you never see is a download button that produces nothing.

The parser runs first

None of this happens until the pasted text resolves to a video ID, and the parser is as strict as the classifier. It accepts the forms people actually paste: the share link https://youtu.be/jNQXAC9IVRw?si=share-tracking-token, tracking string and all, yields jNQXAC9IVRw; the Shorts link https://www.youtube.com/shorts/jNQXAC9IVRw yields jNQXAC9IVRw; a bare ID with stray whitespace yields jNQXAC9IVRw. Every ID it returns is exactly 11 characters of letters, digits, hyphens, and underscores. What it rejects, it rejects with a reason: https://www.youtube.com/playlist?list=PLexampleplaylist fails as playlist-url ("That is a playlist link, not a single video. Open a video in the playlist and paste its URL."); https://www.youtube.com/@examplechannel fails as channel-url ("That is a channel link, not a video. Open one of the channel’s videos and paste that URL."); the lookalike host https://youtube.com.evil.example/watch?v=jNQXAC9IVRw fails as not-a-youtube-url, because the parser checks the whole hostname; and https://www.youtube.com/watch?v=tooshort fails as invalid-video-id ("That link does not contain a valid video ID — YouTube IDs are exactly 11 letters, digits, hyphens, or underscores."). Only a validated ID reaches the URL set and the probes.

How to read the result

"Not available for this video" on sddefault and maxresdefault: YouTube did not serve those sizes for this upload; the largest real image is the highest card that got a button — with both optional sizes missing, hqdefault at 480×360. "Could not be decoded": bytes arrived with a success status but would not decode in your browser. "Open image" instead of "Download JPG": the fetch was blocked in your environment, the size still passed the width check, and the link opens the genuine YouTube URL. If you ever see a size labelled available that was not, or the reverse, the contact page is where that report belongs; confirmed issues are fixed in the engine and pinned with a test. More guides are collected at /guides/.

Frequently asked questions

The downloader this guide describes parses links locally in your browser and never transmits them to this site; your browser fetches the images directly from YouTube. How each check works — including the placeholder-detection trick — is documented on the methodology page.