Safe areas, explained
A “safe area” on a thumbnail is the part of the image that no interface element is drawn over. Video players put chrome on top of thumbnails: a duration badge in the bottom-right corner, hover controls in the top-right, and a watched-progress bar along the bottom edge. The safe-area checker on the size guide draws those zones over an image you load, so you can see which parts of your artwork would sit under them. This guide explains where the zones come from, exactly how big they are at common sizes, how to read the overlay, and what the checker cannot know.
One sentence carries the whole page: the zones are a convention, not a specification. YouTube publishes no overlay spec, the pixels shift with every redesign, and every zone the checker draws is labelled “typical” for that reason. Every figure below is computed at build time by the function the checker runs, so this page and the boxes on screen cannot disagree.
Three zones, one convention
The engine behind the checker is a single pure function, overlayZones(width, height). Given an image size it returns 3 rectangles, each with an id, a label, and a
pixel position measured from the image’s top-left corner. Its header note states the sources of the
convention plainly: duration badges render roughly three to four characters wide in the bottom-right;
hover controls — watch-later and queue buttons — stack in the top-right; the resume-watching bar hugs
the full bottom edge. None of that is a published measurement of any interface; it is a shared pattern
modelled at proportions chosen to be typical rather than exact.
That is why the labels the checker prints are “Duration badge (typical)”, “Hover controls (typical)”, “Watched-progress bar (typical)” — each carrying the word “typical” — and why the size guide says to treat the boxes as “keep important content out of here” rather than as pixel-accurate chrome. The methodology page draws the same line between conventions and cited official figures.
The proportions, recovered from the engine
The zones are defined as fractions of the frame, not as fixed pixel counts, so the badge zone is the same share of a 640-pixel-wide image as of a 3840-pixel-wide one. The engine does not export those fractions directly, but they can be recovered exactly by asking it for the zones of a 1000×1000 frame, where every fraction lands on a whole pixel:
| Zone | Anchored | Width (% of frame) | Height (% of frame) |
|---|---|---|---|
| Duration badge (typical) | bottom-right | 22% | 14% |
| Hover controls (typical) | top-right | 16% | 30% |
| Watched-progress bar (typical) | bottom edge, full width | 100% | 5% |
Two rules turn those fractions into rectangles. Each dimension is multiplied by the frame size
and rounded to the nearest whole pixel. Then the zone is anchored: a right-anchored zone starts
at width − zone width, a bottom-anchored one at height − zone height,
the top-right zone starts at y = 0, and the full-width bar starts at x = 0. The badge and the
bar overlap in the bottom-right corner; the checker draws both, and content under either is
content under an overlay.
The zones at common export sizes
Here is what that produces for four 16:9 frames: 640 pixels wide (the minimum upload
width on Google’s help page, verified July 25, 2026), 1280×720
(the largest size YouTube serves back, maxresdefault), 1920×1080, and 3840×2160 (the resolution guidance on the same help page).
The heights come from the aspect engine — width × 9 ÷ 16 — and
every one of them is a whole pixel, which is what makes these the standard frames.
| Frame | Zone | Left (x) | Top (y) | Width | Height |
|---|---|---|---|---|---|
| 640×360 | Duration badge (typical) | 499 | 310 | 141 | 50 |
| 640×360 | Hover controls (typical) | 538 | 0 | 102 | 108 |
| 640×360 | Watched-progress bar (typical) | 0 | 342 | 640 | 18 |
| 1280×720 | Duration badge (typical) | 998 | 619 | 282 | 101 |
| 1280×720 | Hover controls (typical) | 1075 | 0 | 205 | 216 |
| 1280×720 | Watched-progress bar (typical) | 0 | 684 | 1280 | 36 |
| 1920×1080 | Duration badge (typical) | 1498 | 929 | 422 | 151 |
| 1920×1080 | Hover controls (typical) | 1613 | 0 | 307 | 324 |
| 1920×1080 | Watched-progress bar (typical) | 0 | 1026 | 1920 | 54 |
| 3840×2160 | Duration badge (typical) | 2995 | 1858 | 845 | 302 |
| 3840×2160 | Hover controls (typical) | 3226 | 0 | 614 | 648 |
| 3840×2160 | Watched-progress bar (typical) | 0 | 2052 | 3840 | 108 |
Read down the table and the proportion is constant; only the pixel count changes with the frame. At 1280×720, the reference frame, the region no zone touches is the left 998 pixels of the frame down to y = 619, plus a right-hand band between y = 216 (where the hover zone ends) and y = 619 (where the badge zone begins). Those figures are derived from the engine’s output, not typed in, so if the convention were ever retuned they would change with it.
The same zones at display size
Export size is not display size. The thumbnail tester renders 4 surfaces at typical display sizes — 320×180, 168×94, 246×138, 160×90 pixels — and labels every one of them typical, not a spec, because platforms shift them by a few pixels with each redesign. Running the same zone function at those sizes shows how small the overlays become:
| Surface (typical) | Size | Badge zone | Hover zone | Bar height | Exact 16:9? |
|---|---|---|---|---|---|
| Home grid card (desktop) | 320×180 | 70×25 | 51×54 | 9 | yes |
| Suggested / sidebar row | 168×94 | 37×13 | 27×28 | 5 | no (84:47) |
| Search result row | 246×138 | 54×19 | 39×41 | 7 | no (41:23) |
| Mobile list row | 160×90 | 35×13 | 26×27 | 5 | yes |
Two details matter. First, only 2 of the 4 typical display sizes are exactly 16:9: the sidebar row’s 94-pixel height wants 167.11 pixels of width at 16:9, which the aspect engine flags as rounded, while the mobile row’s 90-pixel height wants exactly 160. That is what “typical” means — measured conventions, with the odd pixel of drift built in. Second, the badge zone on the smallest surface is 35×13 pixels: the same proportion, a very different number of pixels, which is why the zones are proportions rather than pixel counts. The guide to reading the thumbnail tester covers the small-size side of that story.
How to read the checker’s overlay
When you choose a file, the checker decodes it locally with the browser’s own image decoder to
learn its pixel width and height, discards the bitmap, and hands the two numbers to overlayZones. The rectangles come back in pixels; the checker converts each to a percentage of the image so
the boxes scale with the responsive preview, then draws them over the image with their
“(typical)” labels. Nothing is uploaded; the image is shown from an in-memory object URL and
discarded when you leave the page.
Below the preview, a status line reports what the aspect engine found: the pixel dimensions; whether the image is exact 16:9 or, if not, its simplified ratio with a note that players will crop or letterbox it; whether the width meets the 640-pixel minimum; and whether the file is within the 2 MB mobile upload limit (both figures from Google’s help page, verified July 25, 2026). The status line says whether the file is acceptable; the overlay says which parts of it typically get covered.
Reading the boxes is simple: anything under a box is content an interface element may be drawn over on some surface, some of the time. The checker draws all 3 at once and does not predict which will be present, on which surface, for which viewer — so the mechanics-only reading is the useful one: keep the content you need seen out of all of them.
Three common misreadings
“The box is where YouTube’s badge is.” No — the box is where a duration badge typically lands, at typical proportions. It is not traced from any current interface, and the platform publishes none to trace from. Treat its edge as a margin of caution, not a measurement.
“It says my image is not 16:9, but I exported at 16:9.” Check the width. At 1000 pixels wide, 16:9 wants 562.5 pixels of height — not a whole number — so an editor that rounds to 563 produces a 1000×563 file whose simplified ratio is 1000:563, which the ratio check correctly reports as not 16:9. The consequence is tiny: a 16:9 cover slot hides 0.1% of that file’s height. The aspect ratio calculator shows the rounding flag before you export; widths divisible by 16 avoid it.
“The zones are drawn, so they apply.” They are drawn on the frame you loaded. If that frame is not 16:9, a 16:9 surface crops it first — and the zones on the cropped frame are not where the checker drew them. The tester’s crop function makes the effect concrete for common upload shapes:
| Upload | Ratio | In a 16:9 cover slot |
|---|---|---|
| 1280×720 | 16:9 | fits — nothing hidden |
| 1024×768 | 4:3 | 25% of its height hidden |
| 1080×1080 | 1:1 | 43.8% of its height hidden |
| 1080×1920 | 9:16 | 68.4% of its height hidden |
| 2560×1080 | 64:27 | 25% of its width hidden |
For the square and vertical files a large share of the image never reaches the slot, so the corner the badge zone marks on the original is not the corner of what is shown. Load a 16:9 export and the boxes mean what they say.
What the checker cannot know
It cannot know what the interface looks like today. The zones are proportions fixed in a tested module, and they change only when the module changes — not when a platform ships a redesign. That is a deliberate trade: a checker that quietly retuned itself would be claiming knowledge it does not have. When a redesign moves the chrome, the labels stay “typical” and the module is revised in the open, with its tests.
It cannot know which surface your thumbnail will appear on, whether a video will be partly watched, or whether a pointer will hover. It never contacts YouTube — only the pixels of the file you chose are involved — and it makes no judgement about the artwork; it reports geometry. Whether something important sits under a box is for you to decide by looking at the overlay.
The one piece of advice the mechanics support
The mechanics point to exactly one piece of advice about safe areas, and this site stops there: keep the content you need seen out of the typical overlay zones. Around it sit the official rules, a different category of fact because they come from Google’s help article “Add video thumbnails”, re-checked on July 25, 2026: export at 16:9, at least 640 pixels wide, and — the safe intersection of every upload path — under 2 MB. The size guide tabulates those figures with their citation and hosts the checker; a 16:9 export at 1280×720 or larger, loaded there, is the case the zones were built for.
Frequently asked questions
Are the safe-area zones an official YouTube specification?
No. YouTube publishes no overlay specification. The checker’s 3 zones model where a duration badge, hover controls, and a watched-progress bar typically sit, at typical proportions, and every label says so. The official figures — 16:9 and the 640-pixel minimum width — are a different category, cited on the size guide to Google’s help documentation with the date they were verified (July 25, 2026).
How big are the zones on a 1280×720 thumbnail?
The duration-badge zone is 282×101 pixels in the bottom-right corner, starting 998 pixels from the left edge and 619 from the top. The hover-controls zone is 205×216 pixels in the top-right. The watched-progress bar zone runs the full 1280-pixel width and is 36 pixels tall along the bottom edge.
Why does the checker say my image is not 16:9 when I exported at 16:9?
Usually rounding. At 1000 pixels wide, exact 16:9 needs 562.5 pixels of height; an editor that rounds to 563 produces a 1000:563 image, which is not 16:9 — the ratio check is right, and the practical effect is a 0.1% crop of the height in a 16:9 slot. Widths divisible by 16 give whole-pixel heights; the aspect ratio calculator shows the rounding flag before you export.
Does the checker crop my image to 16:9 before drawing the zones?
No. It draws the zones on the frame you loaded. A 16:9 surface crops a non-16:9 image first — a 1080×1080 square loses 43.8% of its height in a 16:9 cover slot — so the zones on the cropped result are not where the checker drew them. Load a 16:9 export to make the overlay meaningful.
Is my image uploaded when I use the checker?
No. The file is decoded by JavaScript in your browser to read its dimensions, displayed from a local object URL, and discarded when you close the page. There is no upload endpoint on this site; your browser’s network inspector will show that no image bytes leave the tab.
Images you load into the safe-area checker are processed locally in your browser and never transmitted; the zone geometry, ratio, and crop figures on this page are computed at build time by the same engines. See the methodology page for how the engines are tested. ThumbnailPro is not affiliated with YouTube or Google.