Why your new thumbnail still shows the old one

First, separate the two problems

“My thumbnail isn't updating” and “my thumbnail isn't showing” look the same from the outside and have nothing to do with each other. The first is a caching question and resolves itself; the second is a file or a permission question and will not resolve until you do something.

The test takes ten seconds: is the old image visible, or is there no image? An old image means a cached copy, and everything in the next few sections applies. A grey box, a black frame or a video-frame still that you did not choose means the custom thumbnail is not in place at all — jump to the last two sections. If what you actually want is to replace a thumbnail — the steps, what it resets, whether an old video is worth it — that is the guide on changing a thumbnail.

The one number that explains it

Thumbnails are served from i.ytimg.com, and that host publishes its caching rules in every response. I requested three different files — a static hqdefault.jpg, a static maxresdefault.jpg and one of the parameterised WebP crops the interface actually uses — and all three answered the same way:

Two hours is the whole story in most cases. It is not YouTube being slow to process your change — the change is already done. It is every cache between YouTube's storage and your eyes being told, correctly, that it may keep serving what it has.

And the URL never changes

This is the part that makes the two hours matter. A thumbnail lives at a path built from the video id — i.ytimg.com/vi/<id>/hqdefault.jpg — with nothing in it that says which version of the image it is. Replace the thumbnail and the address stays byte-for-byte identical, so a cache holding the old bytes has no way to know it should stop.

I checked whether the parameterised variants behave differently, because they carry what look like signatures. They do not: mangling the rs token still returned a valid image, and mangling the sqp parameter returned a differently sized image rather than an error. Those parameters describe the crop, they are not a version stamp. Nothing in the URL space is one.

Which means the mechanism has no invalidation step you can trigger. A cached thumbnail is not cleared; it expires.

Who is holding a copy

Four separate caches, four separate clocks, which is why the update looks so inconsistent — new on your phone, old on your laptop, old for a friend, new in an incognito window.

Your browser. It has the image on disk with the two-hour instruction and will not ask again until that runs out.

The CDN edge that served you. The age header tells you how old its copy was when it answered — I saw values from 0 to 2371 seconds on the same file. A different edge, a different age, so two people on different networks legitimately see different images.

Any app that scraped a link preview. Chat apps, Slack, Discord and forums store their own copy of the preview image on their own schedule, which is usually much longer than two hours and is not yours to control.

Embeds and third-party clients. Anything using the static file paths gets the same two-hour instruction, and anything storing its own copy keeps it as long as it likes.

How to see the current file right now

You do not have to wait to know whether your change landed — you only have to wait for other people to see it. Three checks, cheapest first, and the first one is enough for most people.

The trick behind the first one is that a cache keys on the whole URL, query string included, so any parameter you invent is a new key and therefore a guaranteed fresh fetch. I verified this: hqdefault.jpg?cb=12345 returned 200 with exactly the same bytes as the clean URL and the same etag, which is what you want — a fresh copy of the truth, not a different image.

1. Open the file with a made-up query parameterPaste i.ytimg.com/vi/<your video id>/maxresdefault.jpg?cb=1 in a new tab. Anything after the question mark works; change it each time. What you see is what YouTube's storage currently holds, with no cache in the way.
2. Check the etag from a terminal, if you want proofcurl -I on the same URL prints cache-control, etag and age. Note the etag, make the change, request it again: a different etag means the stored file is genuinely a different image, whatever your browser is still showing you.
3. Only then look at a feedOnce the file itself is right, remaining differences are cache age, not your upload. Nothing you do to the file will make somebody else's copy expire sooner.

What to do, and what not to do

What to do is nothing, for two hours. That sentence is unsatisfying and it is also the whole remedy for the common case: the change is already stored, and the clock is the only thing left.

What not to do is the part worth stating. Do not re-upload the video — the thumbnail is a separate object attached to the same video id, and a new upload throws away every impression and every comment the video has for a problem that a wait would have fixed. Do not change the thumbnail again to “force” it, because each change resets nothing and starts a fresh two-hour window on a fresh image, which is how a ten-minute problem becomes an afternoon.

And if the video is in an active thumbnail test, changing anything mid-flight is the one action that really does cost you something measurable, for the reasons in the guide on A/B testing: you no longer know which variant produced the numbers you are reading.

Link previews are a cache you do not control

When a link to your video is pasted into a chat app, that app fetches the page once, reads og:image — which points at maxresdefault.jpg, as measured in the guide on blurry thumbnails — and keeps its own copy of the preview. From then on the app is showing you its snapshot, not YouTube's file.

There is no general way to clear those, and the two-hour header does not apply to a copy the app has stored itself. Two platforms publish a re-scrape tool for their own cache — Facebook's Sharing Debugger and LinkedIn's Post Inspector — and for everything else the practical answer is that a link posted before the change keeps the old image, and a link posted after it gets the new one.

When it is not a cache at all

If there is no old image but no new one either, the cache is not involved and waiting will not help. Three causes, in order of how often they turn out to be the answer.

Custom thumbnails are not available on the account. The upload silently falls back to an auto-generated frame. This has its own guide, because the requirements changed and the old advice is wrong: why the custom thumbnail option is missing.

The file was rejected. Over the limit for the device you uploaded from — 50 MB on a computer, 2 MB on the phone — an unsupported format, or a policy removal. A rejected upload leaves the previous thumbnail in place, which reads exactly like “my change didn't apply” — check that the file is under the limit and in one of the accepted formats, listed in the size and specs guide.

The derivative you are looking at does not exist. Not every size exists for every video: on a source narrower than 1280 pixels, maxresdefault.jpg returns 404 with a small placeholder body. I verified this on a 2005 upload — maxres and sddefault both 404, hqdefault fine. If you are testing with a URL rather than in the interface, that 404 is about the variant, not about your thumbnail. A removal under the thumbnails policy looks identical from the outside and is not a caching problem at all.

Studio is not proof, and neither is your own feed

Studio shows you the file it has just stored, with no CDN in between, so it updates immediately and tells you nothing about what a viewer sees. Your own feed is the opposite: it is the surface most likely to have a stale copy, because you have visited it most recently and your browser therefore has the oldest cached image of anyone's.

This asymmetry is why “it's updated for me but not for my subscriber” and “it's updated for them but not for me” are both normal in the same two hours, and why neither observation is worth acting on.

The check that avoids the whole problem

Almost every panicked thumbnail swap is a decision that could have been made before publishing. The reason people change a thumbnail an hour after upload is that the feed is the first place they ever saw it next to other videos — and by then the change costs two hours of stale caches and, if a test is running, the test.

Seeing it in a feed first is exactly what the preview tool is for: your thumbnail among real competitors, at the real rendered sizes, before it has a video attached to it. The best fix for a cache problem is not needing the second upload.

The questions everyone asks