Why Your YouTube Thumbnail Looks Blurry: What Happens to Your File Between Export and the Feed

You export the thumbnail, look at it at 100%, and it is sharp. You upload it, refresh the watch page, and something has gone out of it. The text edges have a faint coloured halo. The gradient behind the subject has grown stripes. The whole thing looks like a photograph of your thumbnail rather than the thumbnail.

The usual explanation is that YouTube compressed it, which is true and useless — it tells you nothing about which part of your file was destroyed, or which of your decisions caused it. Compression is not one thing. It is a chain of five separate stages between the export dialogue on your machine and the pixels on a stranger's phone, and each stage degrades a different property of your image. Softness comes from one of them. Coloured fringing around your letterforms comes from another. Banding comes from a third that most creators introduce themselves, in the export, before YouTube has touched anything.

This piece walks the whole chain, then splits "blurry" into the four defects it actually is, and gives each one the specific fix it needs. Most of it is arithmetic you can do yourself, and one of the conclusions is that the file you have been told to upload is already the right size for nearly every screen that is not a television.

The five stages between your export and someone's screen

Here is the pipeline in order. Nothing in it is exotic; it is the same shape as any image delivery system on the web. What makes it worth writing down is that creators tend to blame stage two for damage that happened at stage one or stage four.

1. Your export. Resolution, colour space, bit depth, encoder quality, and whatever the file has already been through before it reached this point.
2. YouTube's re-encode. Your upload is processed into a set of derivative images at fixed sizes, stored on YouTube's image CDN.
3. Format selection. The viewer's browser is served JPEG or WebP depending on what it supports. You do not choose this and cannot influence it.
4. The device downscale. The chosen derivative is scaled to whatever the layout gives it, at whatever pixel density the screen has.
5. Caching. Every layer between the CDN and the viewer's browser can hold a stale copy of the previous version.

Stages two and three are entirely outside your control. Stages one, four and five are where your decisions live, and stage one carries most of the weight.

Stage one: the file you hand over

The floor, and why anything below it is unrecoverable

YouTube's custom thumbnail requirements are a recommended resolution of 1280 × 720, an aspect ratio of 16:9, a minimum width of 640 pixels, and JPG, PNG, GIF or WebP as accepted formats. The thumbnail size guide covers the full specification list.

The minimum width is the trap. A 640-wide file is accepted, so nothing warns you, and then it is upscaled to fill every surface that wants more — which is all of them. Upscaling invents pixels by interpolating between the ones you gave it, and interpolation is a blur operator by definition. There is no recovery from this later in the chain. Every stage after it is subtractive.

The same logic applies to sources you did not author at full size: a screenshot from a 1366-wide laptop display is already below the 1280 you need before you have cropped into it, a frame grab from a 720p video is a compressed image being asked to serve as a source image, and a stock photo downloaded at preview size has already been through one round of lossy encoding. If you need a frame from your own footage, take it from the highest-resolution export you have rather than from the uploaded version — that is what a frame grabber is for.

Generational loss, which nobody watches for

JPEG is lossy on every save, not just the first. Open a JPEG, adjust it, save it again, and you have quantised an already-quantised image. Do that four times across a workflow — export, compress, reopen to fix the crop, save again for upload — and the artefacts from round one become the detail that rounds two, three and four faithfully preserve, while genuine detail keeps thinning out.

The fix is procedural rather than technical: keep a lossless master, and make every export a fresh render from that master rather than an edit of a previous export. If you find yourself opening a JPEG to change something, go back to the layered file instead.

The ceiling that moved

For most of YouTube's history the custom thumbnail limit was 2 MB. In October 2025, 9to5Google reported that YouTube would raise both video and thumbnail file size limits, and through 2026 the thumbnail ceiling has been reaching accounts at 50 MB, framed around 4K-resolution artwork for television screens. Coverage of the rollout has consistently described it as uneven — desktop uploads getting the higher limit well before mobile ones, which stayed at the old figure.

Two practical consequences. First, if your upload is rejected for size, you are on a surface that has not received the change; a modest re-encode gets you under 2 MB without a visible difference, which is what an image compressor is for. Second, and less obvious: a bigger allowance is not an instruction. Filling 50 MB with a noisy 4K render helps precisely one surface, for reasons the arithmetic in stage four makes clear.

Stage two: YouTube re-encodes everything and stores it at fixed sizes

Whatever you upload, what a viewer receives is YouTube's own re-encode of it. The platform's Data API documents the thumbnail sizes it exposes for a video, and the set is short:

Name	Dimensions	Aspect	What it is used for
default	120 × 90	4:3	Dense lists, legacy embeds
medium	320 × 180	16:9	Small tiles and cards
high	480 × 360	4:3	The most widely available derivative
standard	640 × 480	4:3	Mid-size placements
maxres	1280 × 720	16:9	Full-size uses, when it exists

Three things fall out of that table that are worth more than the numbers themselves.

Three of the five are 4:3. Your 16:9 artwork does not become 4:3 by magic — it is fitted into the taller frame with black bars above and below. The lite-youtube-embed project's notes on YouTube thumbnail URLs deal with exactly this, recommending centred background positioning so the bars in the 4:3 images stay hidden. If you have ever seen your thumbnail letterboxed in someone else's embed, in a link preview, or in a third-party tool, this is why. It is not something you did.

The largest documented size is 1280 × 720. That is the same figure as the recommended upload resolution, and it has not changed in the public documentation as the upload ceiling rose. Whatever YouTube's own television client requests for a 4K panel is not visible from outside; what is visible is that the documented ladder still tops out where it always did.

The top of the ladder is not guaranteed. The availability research in that same lite-youtube-embed document found the full-size derivative missing for plenty of videos while the smaller ones were present — which is why every serious embed library falls back down the ladder rather than assuming the biggest file exists.

Stage three: the format you did not choose

Alongside the JPEG derivatives, YouTube stores WebP versions of the same images and serves them to browsers that support the format — which, in 2026, is effectively all of them. Google's own WebP compression study reports files 25% to 34% smaller than JPEG at an equivalent structural similarity index.

Read that number in the direction that matters to you. It is a claim about bytes at fixed quality, not about quality, and in a delivery system that saving usually gets spent on bandwidth rather than fidelity. The practical upshot: the format decision is made per viewer and not by you, and agonising over JPEG versus PNG at upload buys far less than the same effort spent on what is in the frame.

Stage four: the downscale that happens on the viewer's device

This is the stage that decides whether your thumbnail looks sharp, and it is arithmetic rather than opinion.

A layout gives your thumbnail a width in CSS pixels. The screen then draws each CSS pixel using some number of physical pixels — the device pixel ratio, defined in the browser as the ratio of physical resolution to CSS resolution. A ratio of 1 is an old desktop monitor; 2 is a typical high-density laptop; current flagship phones commonly sit between 2.5 and 3. The image you actually need is the CSS width multiplied by that ratio, which is the entire reason a 400-pixel-wide file looks soft in a 400-pixel-wide slot on a phone.

Run it on the surfaces that matter, using the rendered widths from our composition guide:

Surface	Rendered width (CSS px)	Physical pixels demanded	Against a 1280-wide file
Up-next sidebar, desktop	~168	168 at DPR 1, 336 at DPR 2	Massive downscale — 26% at most
Desktop home grid	~360	360 at DPR 1, 720 at DPR 2	Comfortable — 56% at most
Phone feed tile	~360–400	~900–1,200 at DPR 2.5–3	Roughly parity, at the top end
Shelf tile, 4K television	~768	~768	60% — a mild downscale

The single most useful conclusion on this page is in the third row. A modern phone at the top of its density range asks for something close to 1,200 physical pixels across a feed tile, and a 1280-wide file gives it about that. The standard export is not a compromise on mobile; it is roughly a match. Everything else in the table is a downscale, and downscales are the kind of resampling that flatters an image rather than damaging it.

Which reframes the 4K question. The reason to upload something larger than 1280 is not that phones need it — they do not. It is the living room, where the tile is drawn larger and the viewer is further away, and where the geometry of a television does something counter-intuitive to your artwork's apparent size.

One consequence of all that downscaling is worth acting on: sharpen last, and sharpen for the destination size. Detail that reads as crisp at 1280 becomes a fine high-frequency texture at 336 pixels, and fine high-frequency texture is exactly what a lossy encoder spends its bits on and what a resampler averages away. Fine detail is not free. It costs bytes and buys nothing at the sizes where the click is decided.

Stage five: the cache that shows the wrong image entirely

A separate complaint that gets filed under "blurry" is the thumbnail that has not changed at all. You swapped the artwork, Studio shows the new one, and the watch page, the feed or a shared link still shows the old one — sometimes for hours.

Nothing has failed. An image CDN exists to keep copies close to viewers, and those copies expire on their own schedule; on top of that sit the browser's cache, the mobile app's cache and whatever a link-preview service stored when the URL was first shared. Reports from creators put the tail anywhere from minutes to the better part of a day, with the largest derivative and heavily-shared older videos the slowest to catch up. Check from a fresh browser profile rather than a hard refresh, and then leave it alone — there is nothing here to fix. If you are swapping artwork on published videos deliberately, our guide to changing a thumbnail after upload covers what does and does not reset.

Four defects, all called "blurry"

Here is where the diagnosis usually goes wrong. These four failures look superficially similar at a glance and have nothing in common underneath. Identify which one you have before changing anything, because two of the fixes are opposites.

What you see	What it is	Where it came from	Fix
Everything slightly soft, no artefacts	Resampling blur	Source below 1280 wide, or an upscale somewhere in the chain	Rebuild at full resolution; sharpen after the final resize
Square blocks, mush in busy areas	Quantisation blocking	Encoder quality too low, or an image too complex for its budget	Raise export quality; reduce noise and busyness in the frame
Coloured halo or smear at text edges	Chroma subsampling	Colour stored at half resolution against a hard-edged, saturated boundary	Change the colour relationship, not the file settings
Stripes across a gradient or sky	Banding	8-bit quantisation, then a lossy encode that smooths the dither away	Add texture or break the gradient; avoid huge flat ramps

Softness

The most common and the least interesting. If the whole frame is uniformly soft with no visible artefacts, nothing compressed it badly — something scaled it up. Find the smallest element in the chain: a source image, a logo dropped in at 200 pixels wide, a canvas started at the wrong size and enlarged. The one nuance worth knowing is that resizing order matters. Sharpening at full size and then downscaling throws the sharpening away; downscaling and then sharpening for the target size keeps it.

Blocking

Visible square structure, worst in busy regions and around high-contrast edges, is the encoder running out of budget. Two causes, and they call for opposite responses. If your export quality is genuinely low, raise it. If your export quality is already high and the file is still falling apart, the image is too expensive to encode — grain, noise, foliage, glitter, heavy texture overlays and film-grain filters are all high-frequency content that consumes an enormous share of the bits and, at 168 pixels wide, is invisible anyway. In video encoding this is a well-known trade: noise is read as detail, and detail is what bitrate is spent on. Removing texture from a thumbnail is usually a quality improvement, not a sacrifice.

Colour fringing

This is the one that surprises people, because the brightness edges stay sharp while the colours bleed like watercolour. JPEG in its normal configuration stores luminance at full resolution and colour at half resolution horizontally and vertically — 4:2:0 subsampling, on the reasonable assumption that human vision cares far more about brightness detail than colour detail. That assumption holds beautifully for photographs and fails badly for graphics: with four pixels sharing one colour sample, a hard colour boundary that falls inside a block gets one colour for the whole block, and the edge smears. Technical write-ups of chroma upsampling and the perennial bug reports about screenshot compression both land in the same place: for hard-edged coloured text, subsampling is the wrong tool.

Banding

Smooth gradients in 8-bit have a limited number of steps to work with, and a large soft ramp — a sky, a studio backdrop, a radial glow behind a subject — can run out of them and show as stripes. Design tools normally hide this with dither, a fine noise pattern that breaks up the boundaries. Then a lossy encoder, whose whole job is to discard fine noise, removes the dither and restores the stripes. Hence the counter-intuitive advice: the answer to banding in a delivered image is rarely a higher quality setting. It is to give the gradient something to do — a texture, an object crossing it, a vignette that is not a pure ramp — or to avoid full-frame gradients as backgrounds in the first place.

Why red text is the worst case on YouTube specifically

Combine the last two sections and you get a rule with a mechanism behind it. Chroma subsampling damages hard, saturated colour boundaries most. Red on a dark background is the most saturated, hardest boundary in common thumbnail design, and it is also everywhere — red arrows, red circles, red keyword highlights, red outlines. It is the specific combination that produces dark fringes around letterforms and a faint muddy outline that reads, at feed size, as "cheap".

The fixes are all design fixes rather than file fixes, which is why raising the export quality never seems to solve it:

• Put a luminance difference under the colour difference. Red-on-black is a large hue contrast with a modest brightness contrast, so almost all the edge information is in the channel being thrown away. Lightening the red or darkening the background gives the luminance channel — stored at full resolution — something to hold the edge with. Our guide to thumbnail colour works through why luminance structure survives everything that colour structure does not.
• Add a stroke in a different lightness. A dark outline around bright text, or a white one around dark text, is an edge the luminance channel carries by itself.
• Do not use saturated red for the smallest type in the frame. The damage scales with how fine the edge is; a big red shape is fine, five words of red caption are not. The fonts guide covers the sizes that survive the shrink.

The export recipe

Everything above collapses into a short list. This is what to do, in order, for a thumbnail that survives the whole pipeline.

1. Work at 1280 × 720 or higher, natively. 1920 × 1080 or 2560 × 1440 is fine and gives you room to crop. Never build small and scale up.
2. Keep everything in sRGB, 8-bit. A file tagged Display P3 or Adobe RGB is a wide-gamut file being handed to a pipeline that will convert it, and mismatched profile handling is the usual cause of colours that arrive duller or shifted from what you approved. Convert to sRGB in the export, do not merely assign it.
3. Resize first, sharpen second. In that order, always.
4. Export JPEG at quality 85–92, or PNG if the frame is mostly flat graphics and type. Below 80 you are handing YouTube's encoder pre-damaged input; above 92 you are spending file size on detail the ladder will discard.
5. Strip the decorative noise. Grain filters, heavy textures and busy backgrounds cost bits and buy nothing at 168 pixels wide.
6. Check the file size against the limit your upload surface actually has, not the one you read about. If it is rejected, compress rather than re-export at a lower quality from scratch.
7. Judge it at 15% zoom before you upload it, or in a feed preview, next to the thumbnails it will genuinely sit beside.

What a 4K thumbnail actually buys

Given the arithmetic in stage four, the honest answer is: one surface, and it is the one growing fastest. Television is where a tile is drawn at several hundred physical pixels on a panel whose owner paid for resolution. Everywhere else, a 1280-wide file already meets or exceeds what the screen asks for, and the extra pixels are discarded on the way down.

So treat the higher ceiling as headroom rather than a target. Export at 1920 × 1080 or 2560 × 1440 from a clean master if that is easy, keep the quality high enough that you are not feeding artefacts into the re-encode, and spend the rest on the composition — a 4K file of a weak layout is a weak layout at 4K. Nothing in this pipeline improves a thumbnail. It can only fail to ruin one.

AI-generated thumbnails and the softness that comes with them

Generated images have their own version of this problem, and it is worth naming plainly. Image models produce at their own native resolution and aspect ratio, frequently square and frequently not 1280 × 720. Getting from there to a thumbnail involves a crop, a resize and often an upscale — and an upscale is an upscale regardless of how clever the model doing it is. The characteristic result looks impressive at full size and turns to soft, slightly waxy mush in a feed, because the detail was generated rather than resolved and there was never as much of it as the file's dimensions implied.

Two things to check on any generated thumbnail before it goes near an upload. Does it hold up at 15% zoom, where invented micro-detail disappears and only the composition remains? And is the type clean at full size — even letterforms, straight edges, no smeared strokes — or has an image model painted something that merely resembles lettering? Painted lettering is exactly the hard-edged, fine-detailed content that stages two through four handle worst, and it is the first thing to fall apart in a feed.

It is also why the output size of whatever tool you use is worth checking before anything else. Thumblore returns finished thumbnails at 1280 × 720 in 16:9, which is the shape and size the pipeline wants, so no crop-and-upscale step enters the chain at all. That does not exempt you from the design questions above — nothing does — but it removes the failure mode that generated thumbnails hit most often.

The sixty-second diagnostic

If a thumbnail already live on your channel looks wrong, work down this list in order and stop at the first hit.

1. Is it the old artwork? Then it is a cache, and there is nothing to fix. Check again later from a different browser or device.
2. Is the whole frame uniformly soft? Something upscaled. Find the smallest asset in the file and rebuild from a bigger source.
3. Are there blocks and mush in the busy areas? Either the export quality was too low or the frame is too noisy to encode. Cut the texture first; it is usually the cheaper fix and it improves legibility as well.
4. Are the halos only around coloured text and graphics? Chroma subsampling. Change the colour relationship — add luminance contrast, add a stroke, or enlarge the type.
5. Are there stripes in a smooth area? Banding. Break up the gradient rather than raising the quality setting.
6. None of the above, but it looks worse than your monitor promised? Check the colour profile on the export. sRGB, converted rather than assigned.

What the whole chain adds up to is unglamorous and slightly freeing. Almost none of the damage that creators attribute to YouTube's compression was caused by YouTube's compression — it was already in the file, or it was baked into a design decision that a lossy encoder was always going to punish. Fine detail, hard saturated edges, big flat gradients and upscaled sources are the four things this pipeline handles worst, and all four are choices made before the upload button.

Which means the technical fix and the design fix are the same fix. Fewer elements, larger. Contrast built in brightness rather than only in hue. Type big enough that halving its edge resolution does not matter. A thumbnail built that way does not merely compress well — it works at 168 pixels wide in someone's peripheral vision, which is the same requirement wearing different clothes.

For the composition side of that argument, the composition guide is the deep version and the colour guide covers why luminance is the channel that survives. If you would rather not manage resolution, colour space and export settings at all, Thumblore generates at the right size and shape by default — which removes the file problems and leaves you with the interesting one.