How big does thumbnail text have to be?

The short answer

On a 1280 × 720 canvas, make the smallest text you need people to read at least 72 pixels tall — a tenth of the frame height. Ninety pixels is comfortable. Below about 48 pixels, text stops being text and becomes texture.

Those numbers are not a style preference. They come from the smallest place your thumbnail gets shown, and the arithmetic that follows is the entire argument. YouTube's own thumbnail and title tips get as far as “make the text large”; everything below is what happens when you ask how large.

Where your thumbnail is actually shown

A thumbnail is drawn at 1280 pixels wide and displayed at nothing like it. These are the widths the preview tool renders at, matched to the layouts YouTube uses:

Two clusters, and only one of them matters for this question. The browsing surfaces land around 28% of your canvas. The suggested lists — where a viewer who is already watching something decides what to watch next — land at 12.5%. Every sizing rule below is set by that second number, because text that survives there survives everywhere.

What that does to your headline

Multiply your text height by those two percentages and the question answers itself.

Nine pixels is about where a short word set in a heavy weight stops being readable and starts being guessable. Six is where it stops being either. That is the whole reason the answer is 72 and not 48: at 48 your text looks generous on the canvas and is gone in the suggested column.

Stroke width is what actually survives

Height is the number people ask about, but it is not the property that fails first. What fails first is stroke width — the thickness of the lines the letters are made of.

At 12.5%, a stroke that measures 8 pixels in your file lands at one pixel on screen. A light or thin weight, whose strokes might be 4 or 5 pixels at that size, lands at half a pixel, gets averaged with whatever is behind it, and turns grey. This is why a heavy weight at 72 pixels routinely beats a light weight at 96: it is not louder, it is still there.

Practical version: use the heaviest weight of your typeface that still looks like the typeface, and treat 8 pixels of stroke as the floor in the same way you treat 72 pixels of height.

How many words fit, as a number

Word count is not a separate question from size — they trade against each other on the same line, and the trade is calculable.

A bold uppercase character occupies roughly six tenths of its cap height in width. At 72 pixels that is about 43 pixels a character. Your usable width is not the full 1280 but the part that survives the safe zones, call it 1024. Divide and you get about 23 characters on one line.

Twenty-three characters is three short words, or two long ones. That is the real limit, and it is why advice to keep thumbnail text to three or four words keeps being right: it is not a rule about attention span, it is what fits at a size that can be read.

It also explains why a long word is expensive. One twelve-character word eats half the line by itself, and the usual response — set it smaller so it fits — is the move that pushes the whole headline below the legibility floor.

One line or two

The 23-character limit is per line, not per thumbnail, so a second line is the honest way to fit five or six words without shrinking anything. It costs vertical space, and there is plenty of that: two lines at 72 pixels plus leading is around 160 pixels, a little over a fifth of the frame height.

What it really costs is reading order. One line is taken in as a single shape; two lines are read, in sequence, and reading takes time a viewer scrolling a feed does not spend. A second line earns its place when it carries a genuinely separate idea — a setup and a payoff, a subject and a number. It does not earn its place when it is the same sentence broken to fit.

If you find yourself needing three lines, the problem is the copy rather than the type. Three lines at a readable size fills half the frame, leaves no room for the image the words are supposed to be labelling, and will be skimmed rather than read.

Outlines and shadows, and when they backfire

An outline exists to separate letters from a background that is competing with them, and at small sizes it does something else too: it thickens the stroke, which is exactly what downscaling was taking away.

It stops helping when it gets thick enough to close the counters — the enclosed spaces in a, e, o, and the gap in an r. Once those fill in, the word becomes a row of blobs, and at 9 pixels a row of blobs is unreadable in a way that plain thin text at least is not. The failure is invisible at 100% zoom, which is where outlines are usually chosen.

A drop shadow is the gentler tool for the same job, because it adds separation without adding to the letterform. If the background is busy enough that neither is enough, the answer is not a heavier outline — it is to darken or blur the area behind the text, which costs nothing at any size.

Colour stops working before size does

At nine pixels, hue contrast is not contrast. Red text on a blue background looks vivid on your canvas and reads as a single muddy value once the two are averaged into a few pixels each.

What survives is luminance contrast: light against dark, dark against light. A useful check is to look at the design in greyscale — if the text disappears when the colour is removed, it was relying on colour, and colour is the first thing the scale takes away.

The check that replaces the arithmetic

All of this is a proxy for one thing: looking at the design at the size it will be read. The arithmetic is useful because it tells you where to start, but the only reliable test is to see the thumbnail in a feed, next to other thumbnails, at 13%.

It also catches what arithmetic cannot. A headline can clear every number here and still lose because the thumbnail beside it is doing the same thing more clearly. Putting your design into a real feed at real size takes about a minute in the preview tool, and the failures it shows are the ones that were going to happen in front of an audience.

The two mistakes that cause almost all of this

Both are habits of the editor rather than judgements about design.

The first is designing at 100% zoom. At full size, 72-pixel text looks enormous and the temptation is to make it smaller and add a second line. Every decision made at that zoom level is made at a size no viewer will ever see.

The second is writing the title into the thumbnail. On a feed card the title sits right beside or below the image, at a size the interface guarantees is readable. Repeating it in the thumbnail spends the frame's most expensive area duplicating something the viewer is already reading — and it is usually what pushed the text down to an unreadable size in the first place. There is more on how the pair works together in the guide on click-through rate.

Shorts are narrower, so the limit is lower

A vertical frame gives you more height and less width, and text is limited by width. The same 23-character line becomes about 13 characters in a 9:16 frame at the same cap height, which is two short words, not three.

The vertical tiles are also displayed small. Design the words shorter rather than the type smaller — the second option is the one that ends up unreadable. The frame and its surfaces are covered in the guide on Shorts thumbnails.

Questions people ask about this