How to read the thumbnail tester

The thumbnail tester takes an image — a file you choose, or a video's current thumbnail pulled from its URL — and renders it inside generic video-platform mockups at true display sizes, then in a small-size strip, with an optional second image and a grayscale toggle. Each view prints something: a status line with dimensions, a ratio, and a crop percentage; a size on every surface; a label on every slot. This guide explains what each readout means, how it is computed, and where it stops. Every figure below is produced at build time by the module that runs the tool.

The four preview surfaces are typicals, not a spec

The tester renders your image in 4 slots — Home grid card (desktop) at 320×180, Suggested / sidebar row at 168×94, Search result row at 246×138, Mobile list row at 160×90 — each set to a fixed CSS pixel size. Those sizes are honest current typicals of how video platforms size those surfaces — platforms shift them a few pixels with every redesign — so every label says "typical" and none is a specification. What the slot does is exact, though: your browser scales the image into that pixel budget, so what you see is the detail that survives at that size.

Home grid card (desktop) and Mobile list row are exactly 16:9. Suggested / sidebar row and Search result row cannot be: 16:9 at 168 px wide wants 94.5 px of height, and a whole-pixel slot cannot land on a fractional height, so the slot uses 94. The difference is invisible, but it is why aspect-ratio math matters even at preview scale; the tester page tabulates each slot's reduced ratio and the exact 16:9 height its width implies. The 16:9 target is not the tester's invention: Google's help documentation recommends it as the most-used shape in players and previews, cited to Google's "Add video thumbnails" article (verified July 25, 2026) on the size guide.

The text around each slot — title, channel, views-and-time line, duration badge — is editable, because a thumbnail is never displayed alone; a blank duration field hides the badge. The badge sits bottom-right because that is where the convention puts it; safe areas, explained covers that convention and the other typical overlay zones.

Reading the status line

When an image loads, the slot prints one line in a fixed shape: Loaded: label — width×height (ratio); crop sentence. Dimensions are the decoded pixel size of the file — what the bytes contain, not what the file name or an export dialog claims. The ratio is width:height reduced by their greatest common divisor, so 320×180 prints as 16:9 and 1000×562 prints as 500:281. The 16:9 verdict is exact integer arithmetic — width × 9 must equal height × 16 — with no tolerance. The crop sentence comes from the cover-crop report: what a 16:9 slot with a cover fit hides, and on which axis.

The arithmetic is short. An image wider than 16:9 keeps a width of height × 16 ÷ 9 and loses the rest from the sides; a taller one keeps a height of width × 9 ÷ 16 and loses the rest from top and bottom. The lost share is divided by the original axis and rounded to one decimal, so the 4:3 frame at 640×480 loses 25% of its height, while the 64:27 banner loses 25% of its width.

Three misreadings are common. The percentage is of one axis, not of the image's area. It is the same for every 16:9 slot, because a cover fit scales uniformly. And it describes what the slot hides, not anything done to your file — the strip below the mockups shows it whole.

The near miss: why 1000×562 is "not 16:9"

Export at 1000 px wide and the honest 16:9 height is 562.5 px — not a whole pixel, so no export dialog can produce it. Either neighbour reports a sliver: 1000×562 simplifies to 500:281 and hides 0.1% of its width; 1000×563 simplifies to 1000:563 and hides 0.1% of its height. That is a fraction of a pixel at every preview size, reported only because the verdict is exact rather than approximate. A width that divides evenly by 16 — 1280 gives 720 with no rounding — avoids it; the aspect-ratio math guide lists the others.

The legibility strip

Below the mockups, the strip shows the same image at 120px, 168px, 246px wide. Unlike the slots, it sets only the width and lets the height follow the image's own proportions, so nothing is cropped there — a 1:1 image appears square. The widths are not arbitrary: 120 px matches the smallest size YouTube stores for effectively every public video (default, 120×90), and 168 px matches the suggested / sidebar row while 246 px matches the search result row above.

The strip measures nothing. Your browser scales the image down with its ordinary resampling — no sharpening, no enhancement — and the only question it answers is whether what you put in the image can still be made out at that width. The widths are CSS pixels, the same unit the tester's slots use. If it cannot be read at 120 CSS px here, it cannot be read at 120 CSS px on this screen.

The grayscale toggle

The checkbox applies a grayscale filter to every preview and strip image at once, in the page, without touching the file. Hue is removed; lightness stays. Regions that were distinct only because they differed in hue merge; regions that differ in lightness stay separate. That is the entire mechanism — no score, no threshold, no number — and it applies to both slots at once.

A/B mode and the slot labels

Loading a second image into slot B makes every surface render both images with the same title, channel line, metadata, and badge, so the only variable is the image. Each item is captioned with its slot letter and a label. For uploads the label comes from the file name: a trailing extension — the final dot and the short run of letters or digits after it — is removed; underscores and hyphens become spaces; runs of whitespace collapse; anything longer than 40 characters is cut at 39 and given an ellipsis; and a name with nothing left becomes "Uploaded image". Pulled thumbnails are labelled with the video ID and the size key fetched.

.png becomes "Uploaded image" because nothing remains once the extension is gone; the long name becomes "thumbnail episode 12 final final really…" — cut, not summarised. The label is display-only, and the comparison is only that: two images under identical conditions. The tester does not score them, rank them, or predict anything about either.

Pulling a thumbnail from a URL

Each slot's URL field runs the same parser as the downloader, so what the status line prints on a bad paste is the parser's own message rather than a generic error. A watch link carrying a timestamp, a youtu.be share link carrying its tracking string, and the bare ID — https://www.youtube.com/watch?v=jNQXAC9IVRw&t=42s, https://youtu.be/jNQXAC9IVRw?si=share-token, and jNQXAC9IVRw — all resolve to jNQXAC9IVRw; the extras are ignored, not rejected. A playlist link is rejected as playlist-url — "That is a playlist link, not a single video. Open a video in the playlist and paste its URL." — and a lookalike host such as https://youtube.com.evil.example/watch?v=jNQXAC9IVRw as not-a-youtube-url — "That is not a YouTube link. This tool reads youtube.com and youtu.be URLs (or a bare video ID)." The matrix below runs 18 pasted forms through the parser at build time: the 9 forms it accepts, each checked to resolve to the same ID, and 9 of the ways it refuses, each with the code the build asserted and the message the status line prints word for word. The tester page walks the parser's decision order and names the code each branch returns; every rejection the parser can produce, and the awkward variants it normalizes before deciding, are tabulated on the methodology page.

With a valid ID, the tester fetches the stored sizes largest first — maxresdefault → sddefault → hqdefault — skipping the two smallest (default and mqdefault). A size is passed over when the fetch returns a non-ok status or the bytes decode to a placeholder-sized image; the decision on the decoded bytes is the same pure classification the downloader uses. The engine would classify a request for maxresdefault (1280×720) that comes back with a non-ok status as missing — the size was never generated — but the tester skips such a response before classifying, so that verdict never reaches a status line here. The same request that comes back ok but decodes to 120×90 is classified missing: that is the placeholder guard, in case a placeholder ever arrives with an ok status. And a 120×90 decode for default is available, because the guard asks whether the decoded width is both smaller than the width requested and no wider than the placeholder (120 px); for the smallest stored size the first test fails, since 120 px is that size's real width. The full ladder, with each frame's address, shape, and crop, is tabulated on the tester page.

The consequence: maxresdefault (1280×720) exists only for some uploads. When it does not, the tester lands on one of sddefault or hqdefault, each of which YouTube stores in a 4:3 frame — so the status line reports 25% of the height hidden in 16:9 slots. That is the stored frame's shape, not a defect in the artwork; why maxresdefault is missing covers the rest. One more edge: if something in your environment blocks the fetch, the tester still shows the image straight from its YouTube address, but nothing was decoded, so the status line then carries the size the engine expects for that key, not a measured one. Why the fetch normally works is documented on the methodology page.

What the tester does not measure

The boundary deserves stating plainly. The tester does not measure clicks, views, watch time, ranking, or anything about how a thumbnail will do once published; no readout is a proxy for any of those. It does not check the upload rules — minimum width, file-size limits, accepted formats — which live on the size guide with their citation to Google's help documentation (verified July 25, 2026). It does not mark the typical overlay zones; that is the safe-area checker on the same page, and safe areas, explained covers them. It does not enhance, sharpen, or re-encode anything. And it sends nothing anywhere: uploads become in-memory object URLs in your tab, pulled thumbnails are fetched by your own browser directly from YouTube, and both are discarded when you close the page.

Frequently asked questions

Every figure in this guide is computed at build time by the tester's own module, and images you load into the tester are processed locally and never transmitted. The preview sizes and crop math come from the same tested module documented on the methodology page.