The two images a browsing player sees before they click anything

The FiveM server browser is a list of rows, and a row gives you a name, a 96x96 icon, a player count and about twelve words. Click a row and the detail panel adds one more graphic: a 1865x108 strip across the top. That is the whole shop window. Everything else a server owns, the connecting banner, the loading screen, the Discord assets, is seen only after a player has already decided to try it. These two are the ones doing the convincing.

What a row actually shows

Worth being precise about this, because people design for a mental image of the browser rather than the browser. A row is roughly thirty pixels tall at default scale. It carries the icon at the left, the server name, the one-line description, the player count and ping, and nothing else. There is no banner in the list. The strip only appears once a row is selected and the panel opens, which means a meaningful share of players never see it at all.

The consequence is an ordering most people get backwards. The icon and the description are what get you clicked. The strip is what confirms the click was not a mistake. If you have budget for one graphic and twelve words, spend it on the icon and the words, because they are upstream of everything else.

Seventeen to one is unlike anything else

1865 divided by 108 is 17.3. For comparison, a Discord server banner is 1.78, a YouTube thumbnail is 1.78, an X header is 3.0, and the widest thing most designers ever touch is the classic 468x60 web banner at 7.8. The FiveM strip is more than twice as extreme as that. Nothing you have made for anywhere else translates, and nothing made for the strip translates anywhere else.

What the ratio does to a composition is remove the vertical axis entirely. At 108 pixels there is room for one line of display type and a thin element above or below it. Two lines of text does not mean small text, it means unreadable text. A badge, a logo mark and a wordmark side by side does not mean a crowded layout, it means three things each too small to identify. The strip holds roughly one idea.

The other thing it does is make the backdrop almost irrelevant as a scene. A 1920x1080 plate has a sky, a horizon band and a foreground; cropped to 17 to 1 you get a slice of the horizon band and nothing else. This is why strips look flat when they are cut down from a square render. The crop has to be chosen deliberately against a measured horizon line, not taken from the middle of the image.

What survives a crop at both ends

The panel is not a fixed width. The client draws the strip to fill the panel, and the panel narrows with the window, so on a windowed client at 1280 across you lose horizontal content. Importantly the loss comes off both ends rather than off the right, because the image is centred rather than left-aligned. A server name centred in the frame loses its first and last letters symmetrically, which is the one failure that looks like a bug rather than a design choice.

• Keep the outer forty pixels at each end free of anything you need. Treat them as bleed. A clipped panel then eats background.
• Put the wordmark left of centre rather than centred. It reads as a deliberate asymmetric layout at full width and it survives the clip.
• Put the invite in the right third, inside the bleed margin. It is the second most important thing in the frame and it should be the second thing the eye reaches.
• Do not put anything in the extreme left or right as a decorative bookend. Symmetric end furniture is exactly what the crop destroys, and when one end survives and the other does not it looks broken.

The fastest way to check is to open the file and resize the window. If the composition still reads with twelve per cent shaved off each side, it will hold on every client. If it does not, move the lockup rather than shrinking it, because shrinking type on a 108-pixel strip is not a move you have available.

The 96x96 icon, and what reads at that size

96 pixels is small. Thin strokes alias into a smudge, anything occupying less than about a fifth of the frame disappears, and lettering of more than two or three characters is noise rather than text. The honest list of what works at 96x96 is short: a single bold symbol, a monogram of one or two letters at display weight, or a strong geometric shape with high contrast against a dark list background.

A wordmark does not work. This is worth stating flatly because it is the most common mistake in the browser: a server with a five-word name exports its full logo to 96x96 and the result is a grey rectangle with a faint texture. If your logo is a wordmark, you need a separate mark, and deciding what that mark is belongs at the naming stage rather than at the export stage.

Produce it by cutting down from a larger transparent render rather than designing at 96 directly. A 1024x1024 source downscales cleanly to 96, and to 512, 256, 128, 64 and 32 for the Discord icon, the favicon and everything else. Six independent exports always drift: the stroke weight changes, the padding changes, and the smallest copy ends up looking like a different mark. One source, six derived sizes, no decisions made twice.

for s in 512 256 128 96 64 32; do
  magick logo-1024.png -filter Lanczos -resize ${s}x${s} -strip logo-$s.png
done
mv logo-96.png server-icon-96.png

Lanczos rather than the default because it holds edges better at large reductions, and strip because the metadata on a 32-pixel icon is often larger than the image. Run it again whenever the logo changes, which is the real benefit: the six sizes can never fall out of sync with each other because they are regenerated together.

Render above the target, because the panel is drawn at display density

The single most common quality problem in server list artwork is resolution rather than design. The panel is drawn at the player's display density, so a file authored at exactly 1865x108 is being asked to fill 3730x216 physical pixels on a high-density display. Display type is where that shows first and worst: the strokes go soft, the edges fuzz, and the whole strip reads as a resized JPEG even when it is a clean PNG.

The multiplier that works is two for anything above roughly 600 pixels wide and three for anything smaller. So the strip renders at 3730x216 and the connecting banner at 3840x640, while a 468x60 web banner wants 1404x180 and a 300x300 avatar wants 900x900. The small formats need the higher multiplier precisely because they are the ones with the least room for the type to be soft in.

Animated versions are a different trade, because every extra pixel is multiplied by the frame count. There the right move is usually to render motion at the target size or at most double it, and spend the saving on frame rate and palette instead. A 24fps loop with a 240-colour palette at the target size looks considerably better than a 12fps loop with 64 colours at twice the size, at the same file size.

The real GIF budget for the detail strip

An animated strip is a genuine differentiator in a list where nearly everything is static, and it is also the tightest file size budget in the whole pack. Worth doing the arithmetic once rather than exporting and hoping, because the numbers are less forgiving than they look.

The strip animates at 24 frames a second over six seconds, which is 144 frames, rendered at double the target, which is 3730x216 or about 806,000 pixels a frame. That is 116 million pixel samples to fit under a 13MB ceiling, which works out at roughly 0.11 bytes per pixel. The connecting banner by contrast runs 18 frames a second over four seconds at the target size, so 72 frames of 614,000 pixels, about 44 million samples under an 11MB ceiling, or 0.25 bytes per pixel. The strip has less than half the headroom per pixel despite being the smaller image on screen.

GIF compresses by not storing what did not change between frames, which is where the budget actually comes from. Four things decide whether you make it:

1. How much of the frame moves. A scene where one glint crosses a static backdrop compresses enormously better than one where the whole sky drifts. On a 17 to 1 strip a drifting backdrop is barely visible anyway, so this is a free saving.
2. Palette size. 240 colours is the ceiling, not the target. A dusk scene with one accent genuinely needs around 180, and the twenty you save come straight off every frame.
3. Dithering. Heavy dithering on a smooth gradient is the single most expensive thing you can do to a GIF, because it makes every pixel differ between frames and defeats the inter-frame compression entirely. A gentler dither on a plate with real gradients is both smaller and cleaner.
4. Loop seam. A loop that returns to its first frame exactly lets the encoder do its best work on the last frames. A loop that nearly returns costs you a full frame of difference data and shows as a visible hitch.

If after all that it will not fit, cut the frame rate before the resolution. 18 frames a second on a slow scene is visually almost identical to 24 and costs a quarter less. Dropping to the target resolution to keep 24fps is the wrong trade on a format that is drawn at double density.

Twelve words beside the strip

The one-line description, set with sv_projectDesc, is the most under-used asset a FiveM server has. It appears in the list row and again beside the strip in the detail panel, it is free, it takes ten seconds to change, and the overwhelming majority of servers fill it with symbols and a tag soup. It is roughly twelve usable words and they should answer what the server is and who it is for.

What belongs in it: the ruleset, the region, the age gate, whether it is whitelisted, and the invite. What does not belong: emoji, the word custom, a list of script names, the word best, and anything that is true of every server in the list. 'Whitelisted EU roleplay, 18+, serious RP. discord.gg/veloracity' tells a browsing player more than three lines of decoration, and the invite in there is readable by somebody who cannot see images at all.

Pair it with the strip rather than duplicating it. The strip carries the name and the invite as a picture; the description carries the facts as text. A player skimming the list reads the text, a player who opened the panel sees both, and the invite appears twice in two different forms, which is not redundancy but a hedge against either one failing to load or failing to be read.

Sizes people ask for that are not FiveM sizes

A handful of dimensions circulate as FiveM sizes and are not. 1920x1080 as a server banner is almost always somebody describing the loading screen, which is a resource rather than an image slot. 960x540 is the Discord server banner and has no FiveM equivalent. 1280x720 gets requested as a server thumbnail, which is a YouTube thumbnail size repurposed by somebody who assumed the browser shows one. It does not.

The useful test when somebody offers you a FiveM banner at a size you do not recognise is to ask which convar it is for. There are two, they take 1865x108 and 1920x320, and anything else is either the loading screen, a Discord asset, or a misunderstanding. The 96x96 icon is not set by a convar at all, which is the other half of the confusion: it is cut from the logo and referenced by the server, so there is no line in server.cfg to point at.

Getting these two right is not a design achievement, it is a configuration one, and that is the point. A player skimming three hundred rows is pattern-matching for servers that nobody is looking after. A correctly sized icon and a strip that does not clip its own name are how you get out of that bucket, and they cost an afternoon.