Key takeaways
- YouTube Studio is the source of truth. If the thumbnail field in Studio shows your new image, the upload worked, and every remaining symptom is a cache somewhere between YouTube's servers and the screen you are looking at.
- When you swap a thumbnail, the image URL does not change — it is built from the video ID, not from the file. Every cache downstream is keyed on that unchanged URL, which is why one swap goes stale in a dozen places at once and why there is no single refresh button.
- A missing custom thumbnail option is almost never a fault. Custom thumbnails sit behind phone verification, and a single phone number will only verify a couple of channels a year — which is where second-channel owners get stuck.
- Shorts are a separate rollout. Custom covers arrived on 25 July 2026, limited to Partner Programme channels on desktop and delivered in stages, so a missing upload button on a Short is eligibility rather than a bug.
- A thumbnail that was removed for policy does not look like a cache problem once you know the tell: Studio itself falls back to an auto-generated frame you never chose, and an email explains why.
- Third-party link previews run on their own clocks — roughly a month on Facebook, about a week on LinkedIn, minutes on chat apps — and only some of them publish a tool that forces a refetch.
You finish the thumbnail, upload it, and Studio shows it straight away. Then you open the watch page in another tab and the old image is still there. A friend sends a screenshot from their phone with the old image. The link you posted in a Discord server an hour ago still carries artwork you replaced. Somewhere in the middle of all this you start to wonder whether the upload actually worked, so you upload it again.
That is the move that turns a ten-minute wait into an afternoon. "My thumbnail is not showing" describes at least four unrelated failures with four different fixes, and the advice that circulates — clear your cache, wait 24 hours, re-upload — treats them as one. Re-uploading fixes exactly one of them, and makes two of the others slightly worse.
This piece separates them. What Studio can tell you in ten seconds, why the stale-preview problem is structural rather than a glitch, which surfaces you can force to refresh and which you simply have to outlast, and how to tell a caching delay apart from a thumbnail that YouTube has quietly taken down.
Ten seconds of triage before you touch anything
Open YouTube Studio, go to the video, and look at the thumbnail field itself — not the watch page, not your channel page, not the app. Everything that follows depends on what that one field shows, because it is the closest thing you have to a direct view of the video record.
| What Studio shows | What it means | Which failure you have |
|---|---|---|
| The old image, or the upload is refused | The new file never reached the video record | The upload failed |
| Your new image, but the watch page disagrees | The record is updated; something between there and your screen is stale | YouTube-side caching |
| Your new image, and YouTube agrees, but Facebook or Discord do not | Someone else's cache is holding an old copy | Third-party previews |
| An auto-generated video frame you never chose | The custom thumbnail was removed, or was never accepted | Policy, not plumbing |
Nearly every wasted hour on this problem comes from skipping that check and diagnosing from the watch page, which is the one surface guaranteed to be sitting behind a browser cache you control.
Failure one: the upload never landed
The option is missing or greyed out
Custom thumbnails are not a default capability of a new channel. YouTube gates features in tiers: a standard set that every channel has, an intermediate set unlocked by verifying a phone number — longer uploads, live streaming, podcasts and custom thumbnails among them — and an advanced set that needs the phone number plus a second trust signal, which is either channel history, identity verification or a short verification video. There are no subscriber, view or watch-hour requirements anywhere in that ladder for thumbnails. YouTube's account verification documentation covers the process, which takes a couple of minutes by SMS or voice call.
Two details in that system cause most of the confusion. The first is timing: the feature does not always appear in a Studio tab that was already open when you verified, so sign out, sign in and reload before concluding it failed. The second is the quota — a single phone number verifies a limited number of channels per year, commonly described as two. Creators who run a main channel, a clips channel and a client channel from the same number hit that wall without warning, and the symptom is not an error message about phone numbers. It is a missing thumbnail option on the third channel. If you are planning a second channel, verify it the day you create it rather than the day you need a thumbnail on it.
Verify before you need it
Verification is the only part of this whole article that has a deadline attached. Every other failure here resolves in minutes or hours; a phone number that has already spent its allowance for the year resolves when you find another phone number. Do it at channel creation, on every channel, including the ones you are not sure you will use.
The file itself is refused
If the option exists and the upload bounces, it is the file. YouTube accepts JPG, PNG, GIF and WebP, wants 1280 × 720 at 16:9, and enforces a minimum width of 640 pixels — the full list is in the thumbnail size guide. The one that has been moving is the file size ceiling: it sat at 2 MB for most of YouTube's history, and a higher limit framed around 4K artwork has been reaching accounts unevenly since late 2025, desktop before mobile. The practical reading is simple. If your upload is rejected for size, you are on a surface that still enforces the old ceiling, and a re-encode under 2 MB — which an image compressor will do without a visible difference on a photographic thumbnail — gets you through today rather than whenever the rollout reaches you.
Two quieter causes in the same category. A file that has been renamed from PNG to JPG is still a PNG, and uploaders read the bytes rather than the extension. And an export that is technically 1280 × 720 but was upscaled from a 640-wide source will be accepted and then look wrong, which is a different article entirely — the encode chain, rather than the upload, decides that one.
Shorts, which are on their own schedule
For two years a Short's cover was whichever frame you could scrub to. That changed on 25 July 2026, when YouTube began rolling out genuine uploaded covers for Shorts; the rollout was reported as limited to Partner Programme channels on desktop, staged across accounts, and excluded from A/B testing. So on a Short, three different people can be right at once: one sees an upload button, one sees only suggested frames, one sees nothing because they are on mobile. If your upload button is missing on a Short and present on your long-form videos, nothing is broken — the feature has not reached that combination of account and surface yet. Our Shorts cover guide covers what the image is actually for once you have it, which is not the swipe feed.
Live streams have their own version of this. The thumbnail belongs to the broadcast rather than to a finished upload, and the moment at which you can set it differs between a scheduled stream, a stream going live now and the replay afterwards — packaging a live stream walks through all three.
Failure two: it landed, and your screen disagrees
This is the common case, and the fix is mostly patience applied in the right order. Your upload changes the video record immediately; what a viewer sees is a derivative image served from YouTube's image content delivery network, and between that network and your eyes there are at least three more caches — the browser's, the app's, and whatever intermediate layer your network provides.
Work outwards from the layer you control, and stop as soon as one of them shows the new image:
- Hard refresh the watch page. Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on macOS. An ordinary refresh will happily reuse the cached image.
- Open the video in a private window. This bypasses the browser cache entirely and tells you, in one step, whether the problem is your machine or YouTube's.
- Check on a different device, ideally on mobile data. A different browser on the same network still shares some infrastructure; a phone off Wi-Fi does not.
- Clear the YouTube app's cache if the app is the holdout. On Android that is Settings > Apps > YouTube > Storage & cache > Clear cache, which keeps your downloads and your session. iOS has no per-app cache control, so the equivalent is offloading the app in Settings > General > iPhone Storage and reinstalling it.
- Look at what YouTube is actually serving. Pulling the live thumbnail file for the video — which is what a thumbnail downloader does — fetches the current derivative from the image network rather than from any cache of yours. If that file is your new artwork, your work here is done, whatever your browser is still drawing.
Surfaces also refresh on independent schedules, which is why a thumbnail can be correct on the watch page and wrong in search results, or right on your channel page and wrong in a subscriber's home feed, for a while. The watch page is usually first. Grid surfaces, search results and the television app lag it, sometimes by hours rather than minutes.
Three things are worth not doing while you wait. Do not upload the same file again: each upload restarts the propagation without correcting anything, and it makes the eventual result harder to date. Do not delete and re-upload the video, which destroys the only asset an old video genuinely has — changing a thumbnail after upload explains why the algorithm-reset myth behind that instinct is wrong. And do not swap a thumbnail in the middle of a Test & Compare run, because the test is measuring variants that you have just changed underneath it.
Why stale previews are structural, not a glitch
Here is the part that explains the whole third category, and it is the piece almost nobody states plainly.
A YouTube thumbnail's address is derived from the video ID and the name of the derivative size. Swapping the image does not change the video ID, and it does not change the derivative names. The bytes at that address change; the address does not. On your own website you would solve this in five seconds by renaming the file or appending a version string, because every caching layer on the web treats a new URL as new content. You cannot do that here. You are asking a dozen independent systems to notice that a resource they already hold, at a URL that looks identical to the one they fetched last week, now contains a different picture — and the whole design of HTTP caching is built to avoid re-checking exactly that.
That single fact predicts nearly every symptom in this article. It is why the old image persists in link previews long after YouTube itself has moved on. It is why the delay varies wildly between platforms rather than following one rule. It is why "clear your cache" works on your machine and does nothing for the person you are trying to impress. And it is why the only reliable prevention is ordering: set the thumbnail you intend to keep before the link goes anywhere, because every share is a cache being populated with whatever is current at that second.
Failure three: YouTube is right and everywhere else is wrong
Once YouTube is serving the new image, remaining problems live in other companies' caches. Each has its own expiry and its own attitude to being told to refresh.
| Where the old image is stuck | Roughly how long it holds | What actually clears it |
|---|---|---|
| Facebook and Instagram | About a month | The Sharing Debugger, "Scrape Again" — sometimes twice |
| About a week from first share | The Post Inspector, which re-fetches on inspection | |
| X | Around a week | No dependable public tool; time, or a URL the cache has not seen |
| Slack | Tens of minutes, shared across workspaces | Delete the message, wait, post again |
| Discord | Minutes | Re-post the link; it usually refetches on its own |
| WhatsApp, iMessage and similar | Device-level, indefinite in an existing chat | Nothing; the old preview stays in the old message |
| Embeds on your own site | Whatever your poster image and CDN say | Your cache rules, if you hard-coded a thumbnail URL |
| Google Search results | Its own recrawl schedule | Waiting; there is no refresh button for a page you do not own |
Two general-purpose moves work across most of that table. The first is the refresh tool where one exists: Facebook's Sharing Debugger and LinkedIn's Post Inspector both discard the stored preview and re-fetch on demand, and with Facebook it is worth clicking through twice, since the first pass can return an intermediate copy. The second is to share an address the cache has not seen — the youtu.be short form instead of the full watch URL, or the watch URL with a timestamp parameter on it. That forces a fresh scrape of the page. Be honest with yourself about the limit of that trick: it guarantees a re-read of the page, not a re-download of the image, so where a platform caches the picture separately you may still see the old one until its own clock runs out.
The message that already exists is beyond reach either way. A preview rendered into a chat two hours ago is a rendered artefact in someone's message history, not a live lookup, and no amount of cache-busting reaches back into it. If the share mattered, the fix is a new message.
Failure four: the thumbnail was removed
This one masquerades as a caching problem for about a day, until someone notices that the image on the video is a frame from the video itself — one nobody chose, usually badly timed, with a half-closed eye. That is the fallback state. If Studio shows an auto-generated frame where your artwork used to be, the artwork is gone rather than slow.
YouTube's thumbnails policy is the relevant document, and it is stricter than the video policies in one specific way: a thumbnail is shown to people who did not choose to watch anything, so material that would merely age-restrict a video can get a thumbnail removed outright. Sexual content, graphic violence, hateful imagery and thumbnails that materially misrepresent what the video contains are the usual causes. Enforcement has more than one outcome — removal alone, removal plus a warning, removal plus a strike, or an age restriction on the video instead — and a first offence commonly lands as a warning rather than a strike, with policy training available to clear it. Removals come with an email, and there is a long appeal window if you believe the decision is wrong. The mechanics of warnings, strikes and appeals are covered in what a Community Guidelines strike actually does.
The related trap is a thumbnail that is not removed but is treated as sensitive: a blurred or greyed-out preview for some viewers, or an image that fails to appear in recommendation surfaces while remaining on the watch page. Inconsistent visibility across surfaces, on artwork whose subject matter is anywhere near a policy line, is a policy signal rather than a caching one. If you generate thumbnails with AI, the rules that apply to AI thumbnails are worth a read before you assume the problem is technical, because the faces in them are where the real risk sits.
When nothing is broken but the image is still wrong
A separate family of complaints arrives under the same search: the thumbnail shows, but it is cropped, letterboxed with black bars, or soft. None of those are delivery failures.
Black bars above and below come from derivative sizes that are 4:3 rather than 16:9, which some embeds and third-party tools request; your 16:9 artwork is fitted into a taller frame rather than mangled. Cropping on the sides comes from surfaces that fill a differently-shaped tile — the television app and some mobile placements — which is why the composition rules put anything load-bearing away from the edges. Softness is the encode chain, covered in full in the blurry thumbnail piece. If you want to see all of it before publishing rather than after, a thumbnail preview tool renders your file at the sizes the real surfaces use, which is the only honest test of a design you have been staring at full-screen.
The ten-minute diagnostic, in order
- Open Studio and look at the thumbnail field. This decides everything else.
- If Studio shows an auto frame you never chose, check your email for a policy notice before you re-upload anything.
- If the upload is being refused, check the format, then the dimensions, then the file size, then whether the option is even available on that channel.
- If Studio shows your image, hard refresh the watch page, then open it in a private window.
- If the private window is correct, you are done — the rest is your own browser and it will catch up.
- If the private window is wrong, fetch the live thumbnail file directly to see what YouTube is serving right now.
- If that file is correct, wait. Grid surfaces, search and the television app trail the watch page.
- If the app is the last holdout, clear its cache on Android or offload it on iOS.
- Only when YouTube is fully correct, go and fix external previews: Sharing Debugger for Facebook, Post Inspector for LinkedIn, re-post for chat apps.
- Do not re-upload the file at any point in this list. It restarts the clock you are currently waiting on.
How to stop having this problem
Most of the prevention is sequencing rather than technique.
Verify every channel the day you create it. The one failure in this article with a hard external constraint is the phone-number allowance, and it is the one you cannot solve at two in the morning before a launch.
Finish the thumbnail before the link leaves your hands. Every share populates a cache. A video announced in three Discord servers and a newsletter before the final artwork is set will wear the draft for weeks in places you cannot reach.
Keep the layered master, not just the export. Half the re-uploads that cause this are small fixes made by reopening a JPEG, which degrades the file each time. Re-render from the master instead.
Change one thing at a time, and date it. If you swap a thumbnail and a title together during a slow propagation window, you will have no idea afterwards which change moved the click-through rate, and no idea whether the first hour of flat numbers was the packaging or the cache.
Check the preview before you post the link, not after. Paste the URL into the Sharing Debugger once, before the announcement goes out, and you will see exactly what Facebook is about to store for the next month.
The bottom line
"My thumbnail is not showing" is four problems wearing one sentence. One of them is eligibility, one is a file, one is caching, and one is policy — and the ten seconds you spend looking at the thumbnail field in Studio tells you which, before you spend an hour on the wrong one. The caching case, which is most of them, is not a fault to fix but a schedule to outlast, made stubborn by the fact that the address of your thumbnail never changes even when the picture does.
Everything above assumes the artwork itself is worth propagating. If the real reason you are staring at a thumbnail today is that you already suspect it is not working, a caching delay is a distraction from a better question — whether that image earns the click at the size it is actually seen. Thumblore exists to make the second and third concept cheap enough that swapping one is a normal Tuesday rather than a project, and the testing system is what turns a swap into evidence instead of a hunch.
Fix the plumbing once, learn the tells, and then go back to the part that pays: the frame itself.