The size a thumbnail is really seen at
Thumbnails are designed at 1280×720 on a big monitor and consumed at a fraction of that. The numbers are worth internalising, because they explain nearly every thumbnail that underperforms:
| Placement | Rendered width | Share of the design size | What survives |
| Desktop home feed | ~360 px | 28% | Three or four heavy words, one clear subject |
| Mobile feed | ~320 px | 25% | Same, with less patience from the viewer |
| Search results | ~360 px | 28% | As above, competing with a description snippet |
| Suggested / up next | ~168 px | 13% | Shape, colour and one word at most |
| Phone at arm's length | ~120 px effective | 9% | Colour and silhouette only |
At 13% scale, text set at 60 pixels on the original renders about eight pixels tall. That is the arithmetic behind every piece of thumbnail advice you have heard — big text, high contrast, one subject — and it is why judging your own work at full size is misleading.
Titles, and the clamp nobody accounts for
The title field accepts 100 characters, and this is the number most people design around. It is the wrong number. Feeds clamp the title to two lines, and how much fits in two lines depends on the placement width and on the letters themselves — a title in wide capitals runs out of room considerably sooner than the same character count in lowercase.
So there is no reliable character limit to write to. What there is instead is a simple discipline: put the words that carry the meaning in the first forty characters or so, and treat everything after that as a bonus that some viewers will see. Front-loading also serves search, since the earliest words carry the most weight, and it serves someone skimming a feed, who reads the first few words of a title and nothing else.
This tool measures the actual clamp rather than counting characters: each preview flags whether the title overflows the two lines it is given in that specific placement. If the flag appears on the sidebar preview but not the desktop one, that is normal and usually acceptable — if it appears on the desktop feed, rewrite.
Thumbnail and title are one unit, not two
The single most common mistake in a thumbnail is repeating the title inside the image. The two are always seen together, so a thumbnail that says the same thing as the title has spent its entire surface area on information the viewer already has.
The pattern that works is a split: the title states the subject, the thumbnail supplies the tension the title is missing — a result, a face reacting, a before and after, a number, a contradiction. Read the pair aloud as one sentence. If it is redundant, change the image text rather than the title, because the title has search work to do as well.
A few checks that need no data to apply:
- One subject. At 168 pixels there is room for exactly one thing. Two competing subjects read as noise.
- Three to five words maximum in the image, in a heavy weight, at roughly a third of the frame's height.
- Contrast against the feed, not just within the image. A dark, moody thumbnail in a dark-mode feed disappears; a white background in light mode does the same.
- Faces at scale. If a face is in it, make it large enough to read the expression at 168 pixels — an expression is unreadable below roughly a quarter of the frame.
- Keep the bottom-right corner clear. The duration badge sits there and will cover whatever you put underneath it.
Comparing two versions honestly
Side-by-side comparison is the fastest way to make a decision, and it comes with a bias worth knowing about: the left-hand option tends to get the benefit of the doubt. Swap them and check that your preference survives the swap — the swap button exists for exactly this.
Two more habits improve the judgement. Look at the small previews first, because a version that wins at full size but loses at 168 pixels loses in practice. And ask which one you would click if it appeared between two videos you already wanted to watch, rather than which one is better designed — the feed is a competition, not a gallery.
This is a design check, not a click-through rate test. Real A/B testing needs live impressions and the platform's own tools; what happens here is simply making sure the version you upload is the one that still reads at the size it will be seen at, and that its title survives the clamp. That takes thirty seconds per video and catches the errors that cannot be fixed after publishing without losing the early impressions that matter most.
The technical checks, so a re-upload is not needed
Three constraints are hard rules rather than opinions, and all three are checked automatically when you drop an image in: the file must be under 2 MB, the recommended minimum is 1280×720, and the aspect ratio must be exactly 16:9. Anything that is not 16:9 gets cropped or letterboxed somewhere in the interface, and it is rarely cropped where you would choose.
The size rule has a second consequence people miss: a heavily compressed JPEG that squeaks under 2 MB can still show banding and artefacts on a large screen or a TV, where the same image is displayed far larger than any feed. If a re-encode is needed, compress deliberately rather than exporting at the lowest quality that fits.