YouTube Thumbnail Size, Verified

New to the numbers? Start with the guide YouTube thumbnail sizes, explained, which walks through why the upload guidance, the sizes YouTube serves back, and the sizes a viewer's screen actually draws are three different things. This page is the reference behind it: the cited table, the safe-area checker, the 5 stored sizes, and worked examples computed at build time by the same engines that run the tools. More background lives under guides.

The official numbers, cited

Everything in this table comes from Google's help article "Add video thumbnails", re-checked on July 25, 2026:

Rule	Official value
Aspect ratio	16:9 — recommended as the most used in players and previews (podcasts: 1:1)
Minimum width	640 pixels
Resolution guidance	3840×2160 (Google raised this from the long-cited 1280×720)
File size limit	2 MB from mobile (10 MB podcasts); 50 MB from desktop
Formats	Image formats such as JPG, GIF, PNG

Two honest footnotes. First, the famous "1280×720, under 2 MB" rule you see everywhere is not wrong — it is the safe intersection of every device path, and 1280×720 is still the largest size YouTube serves back out (maxresdefault). Second, Google's current page recommends resolution up to 3840×2160, so a 4K export uploads fine — YouTube just downscales it for display. Export at 16:9, at least 1280×720, under 2 MB, and you satisfy both the old rule and the current documentation.

Safe-area checker

Player surfaces draw interface chrome on top of thumbnails: a duration badge in the bottom-right, hover controls in the top-right, and a watched-progress bar along the bottom edge. There is no published specification for these — the zones below model the typical convention at typical proportions, so treat them as "keep important content out of here", not as exact pixels.

What the checker draws, in pixels

The zone geometry is a pure function: give it a width and a height and it returns three rectangles, each a fixed fraction of the frame, anchored to the corner or edge where that piece of chrome conventionally sits. For the working-standard size — 1280×720, the same pixels as maxresdefault — the function returns:

Read that as: the duration-badge zone starts 998 px from the left and 619 px from the top and runs to the bottom-right corner; the hover-control zone occupies the top-right from x = 1075; the progress-bar zone is the bottom 36 px across the full width. Because the fractions are fixed, the zones scale with the image: at 3840×2160 the badge zone becomes 845×302 px, and at the smallest 16:9 export that meets the minimum width, 640×360, it is 141×50 px — the same share of the frame each time. The fractions themselves are the convention, which is why every box carries a "typical" label. The longer discussion of where that convention comes from is in Safe areas, explained.

How the checker reads the corners

Choose an image and four things happen, all inside your browser. First, the file is decoded by the browser's own image decoder to learn its pixel width and height — nothing else about the picture is analysed, and the decoded bitmap is discarded once the dimensions are known. Second, those two numbers go into the zone function shown above, and the three rectangles come back in pixels. Third, the rectangles are drawn over a preview of the image as boxes positioned in percentages of the frame, so they stay aligned however the preview is resized, each carrying its "typical" label. Fourth, a one-line report is printed under the preview: the dimensions; the ratio verdict — either exact 16:9, or the simplified ratio with a note that players will crop or letterbox it; whether the width meets the 640 px minimum; and whether the file is within the 2 MB mobile limit, with the 50 MB desktop figure mentioned when it is not. The preview comes from an in-memory object URL that is revoked when you load the next file. There is no upload endpoint; the methodology page explains how to confirm that in your browser's network panel.

How to read the result

The checker makes no judgement about your design. It shows where interface chrome typically lands and leaves the looking to you: if a face, a word, or a number sits inside a box, that content is at risk of being covered on surfaces that draw that piece of chrome — and only on those surfaces. A box is a warning zone, not a rejection, and an empty box is not a certificate: the zones are conventions at typical proportions, so anything tight against a box edge is in the same category as something just inside it.

The ratio line is stricter than it looks. The engine calls an image 16:9 only when width × 9 equals height × 16 exactly, so a size that was rounded to the nearest pixel can fail the check while being visually indistinguishable from 16:9. The aspect calculator reports 562.5 for a width of 1000 and rounds it to 563; a 1000×563 export therefore describes as 1000:563, the checker says "not 16:9", and the 16:9 cover crop that follows removes 0.1% of its height. That is a real crop, but a tiny one, and the fix — pick a width divisible by 16 — costs nothing. The worked examples further down show the same verdicts for common sizes.

Three limits worth knowing. The checker decodes PNG, JPG, WebP, and GIF; a WebP will be measured even though it is not among the formats Google's page lists, so export the file you actually upload in a listed format. It refuses files above its own size ceiling, and says so, rather than attempting a decode that would stall the page. And it reads pixel dimensions only — a DPI setting stored in the file's metadata changes nothing here, because the platform rules are written in pixels.

The 5 sizes YouTube serves back

Upload guidance and served sizes are different things. Whatever you upload, YouTube stores at most 5 sizes per video at predictable addresses under img.youtube.com/vi/{id}/, and the largest of them, maxresdefault, is 1280×720. This list is the engine's size table, printed at build time:

Two things in that table surprise people. First, 3 of the 5 sizes exist for effectively every public video, while sddefault and maxresdefault are generated only for some uploads — so a downloader that promises every size for every video is promising something YouTube does not store. Second, 3 of the 5 frames are 4:3 rather than 16:9 — the ratio function reports it — so the stored frame is not always the shape of the image you uploaded. Ask the crop report what a 16:9 cover slot does with a 480×360 hqdefault frame and it answers: not a fit, 25% of the height lost. The two 16:9 entries, mqdefault and maxresdefault, are the ones whose pixels correspond directly to your export's shape.

When a size is missing, the server answers HTTP 404 with a gray 120×90 placeholder as the body — an image a plain <img> tag renders without complaint. The classification function that guards the downloader takes two signals and returns one word. Asked about maxresdefault with a failed HTTP status it returns missing; with a successful status but a decoded width of 120 px it still returns missing, because 120 is smaller than the 1280 that was asked for; with a successful status and 1280 decoded pixels it returns available. The same 120-px decode for default — whose real size is 120×90 — returns available, which is why the rule compares against the requested size rather than against a fixed number. Why the two largest sizes are absent for some videos has its own guide: Why maxresdefault is missing.

Why the 640px minimum matters more than the maximum

The minimum is the only hard figure on this page: Google's help documentation states a minimum width of 640 pixels (verified July 25, 2026), and at 16:9 that makes the smallest compliant export 640×360 — a whole-pixel height, no rounding needed. The maximum is guidance rather than a ceiling you will meet in practice: the documented resolution of 3840×2160 is itself exactly 16:9, and a height of 2160 at 16:9 wants a width of 3840, so the guidance figure and the ratio rule agree with each other.

What happens after upload is the part people skip. YouTube serves back at most 1280×720, and the surfaces where a thumbnail is actually seen are smaller still. The thumbnail tester renders its previews at 160 to 320 px wide — honest current typicals of how video platforms size those surfaces, not a spec — and its legibility strip goes down to 120 px. A 1280-wide maxresdefault is drawn roughly 8× smaller on the tester's narrowest typical surface; a 3840-wide export is drawn roughly 24× smaller. Extra resolution above the minimum changes how the image survives that downscaling; whether a given design survives it is something the tester shows and this page does not guess at.

Worked examples: what the checker says about common exports

Every verdict below is computed at build time by the same ratio and crop functions the checker calls, so the table cannot disagree with the tool:

Reading down the crop column: the exact-16:9 rows lose nothing; the rounded 1000-wide export loses a fraction of a percent; the 16:10 export loses 10% of its height; the 4:3 export loses 25% of its height; and the square cover loses 43.8% of its height, which is what "1:1 for podcasts, 16:9 for videos" looks like in pixels. The 320×180 row is a trap worth naming: it is exactly 16:9 and it is a size YouTube serves back, but it is below the documented minimum width — so a mqdefault saved from the downloader is not a file you can re-upload as a thumbnail under the cited rules, whereas a maxresdefault at 1280×720 is.

Frequently asked questions

Official figures verified against Google's help documentation on July 25, 2026; conventions are labeled as conventions. If Google changes the rules, the contact page is the fastest way to tell us. ThumbnailPro is not affiliated with YouTube or Google.