Loading
Why your FiveM banner is not showing: the sets prefix, direct image URLs, HTTPS, and the client-side cache that keeps serving the old file after you replace it.
6 min read
Both FiveM banners are convars, not uploads. You put a line in server.cfg pointing at a URL, the server replicates that value to every connecting client, and the client fetches the image itself. That design is why the banners are free to host wherever you like, and also why there are four separate ways to get it wrong, each of which produces the same symptom: nothing appears.
sets banner_detail "https://cdn.example.com/velora/detail-v3.png"
sets banner_connecting "https://cdn.example.com/velora/connecting-v3.png"banner_detail is the 1865x108 strip drawn across the top of your server's detail panel in the server browser. banner_connecting is the 1920x320 band drawn on the connecting dialog while a player joins. They are independent, they take different sizes, and setting one does not affect the other. Put them anywhere in server.cfg; convar order does not matter.
This is the most common failure and the least obvious, because the server starts without complaining. FiveM has three convar-setting commands and they differ in who can see the value.
| Command | Visible to | Use for |
|---|---|---|
| set | The server only | Internal configuration, resource settings |
| sets | The server and every client | Anything the client has to read, including both banners |
| setr | The server and clients, as a replicated convar | Values a client script reads with GetConvar |
The banners have to be readable by the client, because the client is what fetches the image. A plain set stores the value server-side and the client never learns about it, so the panel renders with no banner and nothing in the console suggests why. If your banner is not showing and you have not checked this, check this first.
The client performs a plain HTTP GET and expects image bytes back. A surprising number of URLs that look like images are not. A link to a Discord message attachment page, an Imgur gallery URL, a Google Drive sharing link and a Dropbox share link all return HTML containing a reference to the image, not the image. The client gets a document, fails to decode it and shows nothing.
The test is quick: open the URL in a private browser window. If you see the image on a white background with nothing else, and the address bar still shows the same URL, it is a direct image. If you see any page furniture, or the URL changed, it is not.
Discord CDN links deserve a specific warning. They used to work and many guides still recommend them. Discord now appends signed expiry parameters to attachment URLs, so a link that works today returns a 403 in a matter of days or weeks. A server whose banners vanished without anybody touching server.cfg is almost always a server using Discord attachment URLs.
Use HTTPS. Plain HTTP fetches are unreliable from the client and there is no reason to host an image over HTTP in the first place. Any static host will give you a certificate for nothing, and if you are serving from your own box, a reverse proxy with an automatic certificate takes ten minutes to set up once and then never needs touching.
A related trap: a URL that redirects from HTTP to HTTPS is not the same as an HTTPS URL. Write the HTTPS URL in the convar directly rather than relying on a redirect, because the fetch does not necessarily follow one.
This is the one that costs people an afternoon. The FiveM client caches banner images aggressively and does not revalidate them on a schedule you can predict. If you overwrite detail.png on your host with new artwork, a player who has already opened your detail panel keeps seeing the old image, potentially for a very long time. You will see the new one because you cleared your own cache while testing, which makes the problem look like it is fixed when it is not.
The fix is to never overwrite a banner file. Version the filename, update the convar and restart:
sets banner_detail "https://cdn.example.com/velora/detail-v4.png"Keep the old files on the host rather than deleting them, so clients mid-session that still hold the old URL get a 200 rather than a 404. Costs you a few kilobytes and saves a confusing week.
The requirements are small: HTTPS, a stable URL, and a host that will not rate-limit you when a few thousand clients fetch the same file. That rules out personal Discord servers and most free image hosts, and leaves a lot of good options.
Set long cache headers on the files deliberately. Since you are versioning filenames anyway, a one-year immutable cache header is correct and reduces the number of fetches your host sees to roughly one per player.
Both convars accept a GIF at the URL, and an animated banner is a genuine differentiator in a list where most entries are static. There are two things to weigh.
The first is size. Every client that opens your panel downloads the file, and every client that joins downloads the connecting banner. A GIF large enough to look good at 1865x108 is a few megabytes; one encoded carelessly is twenty. Keep the frame count modest, keep the palette tuned to the scene rather than full, and check the resulting file size rather than assuming. Six seconds at 24 frames a second is 144 frames, which is already a lot of data at that width.
The second is that you should host a still as well, at its own versioned URL, even if you are serving the animation. It costs nothing to keep around and it means switching back is a one-line change rather than a re-render, which matters if you ever need to cut your host's bandwidth in a hurry.
That last step is the one people skip and it is the only one that actually tests the thing you changed. Your own client has every version of your banner you have ever shipped sitting in its cache. A friend's client has none of them, which is the state every new player is in.
While you are in server.cfg, the two text convars that appear beside your banner in the browser are worth getting right at the same time:
sets sv_projectName "Velora Roleplay"
sets sv_projectDesc "Whitelisted EU roleplay. discord.gg/veloracity"The description is the line underneath your name in the detail panel, next to the strip. A banner carrying your invite and a description that repeats it is not redundant, it is the invite being readable both to somebody skimming the list and to somebody who can only see the picture.