English

Video & subtitles · YouTube Thumbnail Downloader & Metadata Viewer

YouTube thumbnail sizes explained: default, mq, hq, sd and maxres

· Background

youtube thumbnails image-formats

Eight JPEG thumbnail frames and five linked WebP poster variants
Original ToolAcre vector illustration

The five named thumbnail sizes have different dimensions, aspect ratios and availability. This post explains what each name means, where it is used on the platform and which one to pick for a given job.

Eight JPEG candidates and five WebP poster links, not five total images

A YouTube thumbnail is not one file. ToolAcre defines eight JPEG candidates: `maxresdefault`, `sddefault`, `hqdefault`, `mqdefault`, `default`, `hq1`, `hq2` and `hq3`. The first five are poster roles; the numbered names are frame stills that may show different moments even when their dimensions match a poster. Record the role before sorting by pixel count.

It also constructs WebP links for the five posters under `vi_webp`. JPEG bodies can be read, decoded, measured and retained as Blobs; WebP responses lack permission for that cross-origin workflow. The exact inventory is eight probed JPEGs plus five linked WebP counterparts, not thirteen equally verified downloads.

default and mqdefault — the small sizes used in lists and suggestions

`default` is nominally 120×90 and 4:3; `mqdefault` is 320×180 and 16:9. Aspect ratio can change framing or introduce bars, so the smaller file is not merely a reduced copy. Nominal sizes describe expectations; ToolAcre decodes the live response because the URL pattern does not guarantee its body.

YouTube can also return 120×90 as a placeholder when a larger option is absent. ToolAcre rejects those dimensions for larger names but accepts them for genuine `default`. Thus neither rejecting every 120×90 response nor trusting every HTTP 200 misclassifies availability. Visual usefulness still requires inspection. The variant name supplies the context needed to interpret identical dimensions.

hqdefault and sddefault — the 4:3 sizes, their black bars and where they still appear

`hqdefault` is nominally 480×360 and `sddefault` 640×480, both 4:3. A widescreen source may contain letterbox bars inside the JPEG; stretching distorts them with the picture, while covering crops content. Inspect the decoded file instead of selecting `sddefault` only because its width is larger.

`hqdefault` is broadly reliable and `sddefault` optional, but ToolAcre requests both and reports status, bytes and decoded dimensions. An upload may supply the former while the latter fails or returns a placeholder. Even successful `sddefault` may fit worse than widescreen `mqdefault`. Layout, resolution and reuse permission are separate decisions. Compare composition before favoring the larger byte or pixel count.

maxresdefault — the 16:9 full-size image and why it is not always present

`maxresdefault` is nominally 1280×720 and 16:9, making it the first large widescreen candidate, but it is optional. Its association with source video of at least 720p is not an availability guarantee. A predictable URL creates no asset; only a successful, decodable response proves current signed-out delivery.

It may return 404, another error, undecodable bytes or HTTP 200 with a 120×90 fallback. ToolAcre decodes before ranking it, preventing a tiny placeholder from being upscaled under a persuasive filename. Lower candidates remain available for comparison; the tool cannot recover an unpublished poster or infer historical availability from playback quality. Current video resolution is not substitute evidence for the missing file.

Choosing a size — web previews, slides, print and archives, matched to resolution and aspect ratio

Choose with actual pixels, aspect ratio and visual content. A slide may favor 1280×720 `maxresdefault`, a small card 320×180 `mqdefault`, and a 4:3 tile `hqdefault`. Review numbered frames because they may show a different scene. Names predict role and nominal shape, not design fitness.

Enlarging 320×180 artwork interpolates existing pixels without recovering detail, and even 1280×720 may fail a print specification. ToolAcre reports bytes and dimensions, not DPI, sharpness or licensing. Compare destination requirements, seek a higher-resolution authorized source when necessary, and preserve the original before any permitted crop or conversion.

Worked example: compare five posters and three frame stills

Suppose a lecture returns 1280×720 `maxresdefault`, 480×360 `hqdefault`, 320×180 `mqdefault`, 120×90 `default`, and three 480×360 frames; `sddefault` returns a 120×90 placeholder. The poster carries the title, while frames show an opening slide, speaker and diagram. Equal dimensions do not imply equal editorial meaning.

Mark `sddefault` missing despite HTTP 200. The operator may choose `maxresdefault` for a course page and `hq2` only when the speaker still is appropriate and permitted. Stable paths can later serve new bytes, so reproducibility requires preserving the file and access date alongside state, dimensions, bytes and role. A filename alone cannot preserve that evidence.

WebP covers the five poster names; numbered frames are JPEG-only

WebP covers only `maxresdefault`, `sddefault`, `hqdefault`, `mqdefault` and `default`. The builder rejects WebP `hq1`, `hq2` and `hq3` rather than inventing addresses. Supported links use `https://i.ytimg.com/vi_webp/VIDEO_ID/VARIANT.webp`, but missing CORS permission prevents JavaScript from verifying dimensions or retaining a Blob.

Users may open or copy a WebP link while ToolAcre cannot promise a renamed download or measured bytes. Proxies may block either family independently. An undisclosed backend would change the privacy model, so measured WebP savings require a permitted external comparison. Extension and matching role alone prove neither size, quality nor availability.

Takeaway: pick by purpose — how the YouTube Thumbnail Downloader lists every size so you can choose

The exact inventory is eight JPEG candidates, five posters and three frames, plus five WebP poster links. Parsing is local until Fetch. Then eight direct image GETs and separate oEmbed traffic omit credentials and referrer, request no-store and follow redirects. Google sees requests and Origin; no ToolAcre proxy intervenes. Results prove current responses, not history, ownership or permission.

Treat the variant table as eight separate observations, not one network verdict. Each direct JPEG request reaches Google after Fetch without credentials or referrer and can independently meet an error, placeholder or decode failure; signed-out restrictions still apply. The separate oEmbed branch may fail at transport, HTTP or JSON without changing an image row. “All variants” means every implemented candidate was checked, so retain each row’s dimensions, bytes or failure reason rather than collapsing the evidence.