Your token image is not showing

Where the image actually comes from

Understanding the chain of requests explains every failure in this category, and it is shorter than people expect.

Your token has a metadata account on-chain. That account stores a URI, which points at a JSON file somewhere on the internet. The JSON contains the name, the symbol, a description and an image field, and that image field points at another URL. A wallet fetches the JSON, reads the image URL, then fetches the image.

Three things follow. The image is not stored on-chain, so the chain cannot guarantee it exists. There are two separate network requests, either of which can fail on its own. And both destinations are outside Solana's control entirely, which means their availability is somebody else's operational problem that becomes yours.

Six reasons it does not appear

The diagnostic value of the middle column is high. If the name and symbol display correctly but the image does not, the metadata JSON is being read successfully and the problem is one layer further out. If nothing displays at all, the failure is at the first request.

The hosting mistake almost everyone makes

By far the most common cause of an image that vanishes weeks after a successful launch is where it was hosted in the first place.

During launch, speed matters and people use whatever is fastest: a free image host, a link copied from somewhere temporary, a personal server, a URL from a service that was never meant to serve production traffic. It works on the day, which is why nobody revisits it.

Then the free host expires the file, or rate-limits it, or the server goes down, or the service changes its rules. The metadata still points there faithfully, and now your token has a broken image and you find out from a community member rather than from monitoring.

The fix is to point metadata at storage designed to be permanent, or at minimum at infrastructure you control and pay for. If the update authority has already been revoked, the URI cannot be changed at all, and the only remaining lever is controlling what that URI returns. That asymmetry is worth understanding before revoking anything, which the on-chain reading guide covers alongside the other authority fields.

Caching, and why fixes look like failures

This is where teams waste the most time after having already solved the problem.

Every wallet, screener and aggregator caches metadata and images independently, on its own schedule, with its own rules. Some cache successful responses for a long time. Some cache failures too, which means an interface that tried while your image was broken may keep showing nothing long after it works.

The consequence is that refreshing an app proves nothing. The only reliable verification is to fetch the metadata URI and the image URL yourself, directly, and confirm both return what they should. If they do, the fix is correct and the remaining wait is somebody else's cache expiring.

Expect an uneven recovery: one interface updates in minutes, another the next day, a third only when something forces it. That unevenness is normal and is not evidence that the fix failed.

One further wrinkle affects screeners specifically. Several of them do not read your metadata at all for the picture they display; they use their own records, populated when the pair was first indexed or supplied through their own submission process. That means an image can be correct everywhere in the wallet ecosystem and still wrong on the surface most visitors actually browse. If a screener shows the wrong logo or none while wallets are fine, the fix is on their side rather than yours, and it usually means using whatever update process that particular site provides. The stale data guide covers the same divide between what the chain says and what a given interface has stored.

A five-minute check

1. Open the mint in an explorer and find the metadata URI.
2. Open that URI in a browser. Does it return JSON, and does the JSON parse?
3. Find the image field in that JSON and open its URL directly.
4. Check what is serving it. Permanent storage, or something temporary you forgot about?
5. Check the format. A standard PNG at a modest file size avoids a whole class of inconsistent behaviour.
6. Confirm both URLs work from a different network, so you are not testing your own cache.

Nearly every case resolves at step two or three, and both take seconds. The reason this is worth doing properly once is that the same chain of requests is behind several other symptoms, including tokens that display no name at all and tokens that look fine in one wallet and broken in another.

One habit prevents the whole category from recurring. After any metadata change, and once a month afterwards, fetch both URLs and confirm they still return what they should. It takes seconds and it catches the silent failure mode, which is hosting that worked for six weeks and then quietly stopped. Nobody monitors their own token image, which is precisely why a broken one can sit there for a month before a community member mentions it, by which point every visitor in that window has already formed an impression.

Why this is not cosmetic

It is tempting to file a missing logo under polish and get to it later. The evaluation sequence argues otherwise.

Someone arriving at your token spends a few seconds forming an impression before reading a single number. A blank placeholder where a logo should be says, accurately, that something about this token has not been finished. That impression colours everything they look at afterwards, including figures that would otherwise have been read favourably.

It also compounds with the other visibility problems. A token that is not searchable by name yet, for the reasons covered in the aggregator listing guide, and also has no image, is very hard for anyone to recognise or share. Both are fixable in an afternoon and both are routinely left for weeks, usually because they feel less urgent than whatever is happening with the chart. They are cheaper than everything else on that list and they are the first things anyone sees.