Minecraft MOTD, server icon and resource packs

Three small things decide what a player sees before they have joined and what the world looks like once they have: the MOTD line in server.properties, a server-icon.png that is exactly 64 pixels square, and a resource pack served from a URL with a matching SHA-1 hash. None of them is difficult, and all three fail silently in the same way - the server starts, nothing appears, and no error is obvious. This post covers where each one comes from, the exact syntax including the escape that colour codes need, and the specific reasons a pack refuses to download.

What the server list entry is made of#

When a player's client has your address saved, it opens a short connection and asks for status. Your server answers with a small block of JSON and then a ping to measure latency. Everything in the list entry comes from that reply:

• The description, which is your MOTD, as a formatted text component on two lines.
• The player counts, online and maximum, plus a sample of names shown when the cursor hovers over the count.
• The version name and protocol number, which is what produces the red "Outdated client" text when they do not match.
• The favicon, a 64x64 PNG encoded into the reply itself.

The whole exchange happens before any authentication, which is why the entry works even for a server you cannot join. It is also why enable-status=false in server.properties makes a running server look offline to everyone: the server simply refuses to answer the question. That setting is occasionally useful for a private server, and occasionally the reason somebody spends an hour debugging a firewall that is fine.

One more thing to know before you start editing: if you run a proxy, the proxy answers the status request, not the backend. The MOTD, icon and player counts all come from the proxy's own configuration, and nothing you set on the Paper server behind it will ever be shown. That catches people the day they add a Velocity proxy to a working server.

Writing the MOTD#

motd lives in server.properties in the server root, and it defaults to A Minecraft Server. The file is a Java properties file, which gives you two useful escapes and one trap.

motd=§6§lTHE MINE§r §7| §avanilla survival 1.21\n§8no whitelist §7- §fmc.example.com

\n starts the second line. § is the section sign, the character that introduces a formatting code. You can sometimes paste a literal section sign into the file and have it work, but whether it survives depends on the encoding the file is saved in and the editor that saved it, so the escape is the version that always works. The panel's file editor writes UTF-8; a text editor on Windows may not.

A few rules that are not written down anywhere obvious. Formatting codes do not stack the way you expect: a colour code resets the formatting, so §l§a is bold green but §a§l is green then bold, which is the same thing only by accident of ordering - put the colour first and the style second and you will not be surprised. §r resets both. And the client clips each line at the width of the list entry, which is somewhere around 45 characters of normal text, less with bold. Write the second line as the throwaway and put the important word first.

For anything beyond the sixteen legacy colours - gradients, per-character RGB - use a plugin that supplies the MOTD as a full text component at ping time. Paper understands the Bungee-style §x hex sequence in a lot of places, but the MOTD is exactly the place to test rather than assume, because the failure mode is a line of visible junk characters in a public list. A MOTD plugin is also how you get a random line per ping, a maintenance message, or a different MOTD for outdated clients.

Obfuscated text (§k) in a MOTD animates on every frame and looks like a broken font on half the listing sites that scrape it. Use it for one word at most, or not at all.

server-icon.png#

The icon is a file called exactly server-icon.png, in the server's root directory - the same folder as server.properties and the world folder, not inside plugins/.

It must be a PNG that is exactly 64 by 64 pixels. Not 128, not 63, not a JPEG renamed to .png. Transparency is supported and looks good against the dark list background. Anything else and the server prints a line at startup and carries on without an icon:

[Server thread/WARN]: Couldn't load server icon

The file is read once at startup and then held in memory, so changing it needs a restart rather than a reload. On the panel, upload it through the file manager into the server root, then restart from the console. A player whose client is still showing the old icon should refresh the multiplayer list; if it persists, deleting and re-adding the server entry always clears it.

If the image you want is not square, crop it rather than squashing it. Sixty-four pixels is small enough that fine detail disappears, so a single bold shape reads far better than a logo with text in it.

The player count line#

max-players in server.properties is the number on the right of the entry, and it is the number the server actually enforces. Raising it does not make the server able to hold that many people; it only removes the refusal. What your plan can genuinely hold is a memory and CPU question, covered in how many players fit on a server.

hide-online-players defaults to false. Setting it to true removes the sample of names from the hover tooltip while leaving the counts. That is a reasonable privacy setting for a private server and does nothing for a public one.

Plugins that invent player counts exist. They are worth avoiding: the numbers are trivially checked against the query port, several listing sites treat it as grounds for removal, and a server that claims forty players and has three is a worse first impression than one that honestly has three.

Resource packs: the four properties#

A server can ask every joining client to download and apply a resource pack. Four keys in server.properties control it, and they are all empty by default.

resource-pack=https://packs.example.com/themine-v7.zipresource-pack-sha1=2fd4e1c67a2d28fced849ee1bb76e7391b93eb12require-resource-pack=falseresource-pack-prompt={"text":"Our pack adds custom block sounds and item models."}

On 1.20.3 and later there is also resource-pack-id, a UUID identifying the pack, which exists because that version added the ability to have several packs applied at once and to add or remove them individually at runtime. On older versions there is one pack and it replaces whatever came before.

The zip itself has to be built correctly or the client rejects it as an invalid pack. pack.mcmeta must be at the top level of the archive, alongside assets/. The most common mistake in the world is selecting the pack folder and compressing it, which produces MyPack/pack.mcmeta one level down. Select the contents, not the folder. Inside pack.mcmeta, pack_format is a number tied to the game version; when it does not match, most versions load the pack anyway with a warning about it being made for a different version, and some features silently do not apply.

Hosting the zip, and getting the hash right#

The URL is fetched by the client, not by the server. It has to be publicly reachable over HTTP or HTTPS, return the file directly with a 200, and not bounce through an HTML page first. That rules out the share links from consumer file-sharing services, which serve a web page with a download button rather than the file. It also rules out anything behind a bot-protection challenge.

Check it from a machine that is not your server:

$ curl -IL https://packs.example.com/themine-v7.zipHTTP/2 200content-type: application/zipcontent-length: 4823914

A 302 to something ending in .html, a 403, or a content-type of text/html all mean the client will fail. Any small static host works: a web hosting plan, an object store with public objects, or a release asset on a code host. RE:NODE's web plans serve static files from $3 a month and include a reverse-proxy slot - point an A record at the address shown and the certificate is issued and renewed for you, so the pack URL is HTTPS without any work. The certificate side of that is in your domain and its certificate.

Now the hash. SHA-1 is how the client knows whether the copy it already has is current:

$ sha1sum themine-v7.zip2fd4e1c67a2d28fced849ee1bb76e7391b93eb12  themine-v7.zip

On Windows, certutil -hashfile themine-v7.zip SHA1, or Get-FileHash -Algorithm SHA1 themine-v7.zip in PowerShell. Paste the value in lowercase with no spaces.

Three things go wrong here, and all three are avoidable:

• No hash at all. The pack still works, but the client cannot tell whether its cached copy matches, so it re-downloads on every join. On a 40 MB pack that is a very slow join screen.
• A stale hash. You updated the zip and not the property. The client downloads the file, finds it does not match, and refuses or warns. Update both together, always.
• A cached URL. Some clients and most intermediary caches key on the URL. Change the filename every time you change the contents - themine-v7.zip, then themine-v8.zip - and the whole class of problem disappears.

Keep the pack small. The client refuses very large packs outright - the ceiling is around 100 MB on modern versions and was half that on older ones - but the number that matters is not the limit, it is the join time. A player on a slow connection watching a 60 MB download before they can see your spawn will often just leave. Under 10 MB is a good target, and most of the weight is usually uncompressed textures at resolutions nobody can see.

Forcing a pack, and whether you should#

require-resource-pack=true turns the pack from an offer into a condition: decline it, and you are disconnected. resource-pack-prompt is your one chance to explain why, so use it for a sentence of reassurance rather than a slogan.

Two honest reasons not to force it. First, a player whose client has "Server Resource Packs" set to Disabled in that server's entry declines automatically, without ever seeing the prompt, and is kicked with a message they will read as "this server is broken". Second, forcing adds a download to the critical path of a first join, which is the single most fragile moment in a new player's relationship with your server.

Forcing is right when the pack is load-bearing - custom items whose models are the gameplay, a map that depends on custom sounds. Everything else is better off optional, or pushed per-player by a plugin after they have joined, which most pack-management plugins support through the same mechanism the server uses.

Bedrock players reached through Geyser are a separate case entirely: they cannot read a Java pack, because Bedrock uses a different pack format. Geyser serves Bedrock packs from its own packs/ folder, so a crossplay server that cares about appearance maintains two. That is covered in Geyser and Floodgate.

Troubleshooting#

The MOTD in the list is the old one. The client caches the entry until the list is refreshed. Press refresh, or leave and re-enter the multiplayer screen. If it never updates, a proxy is answering the ping.

Colour codes show as literal text. Either a real section sign was written into the file in an encoding the server did not read as one, or a code was typed with a & instead. & codes are a plugin convention; vanilla server.properties needs the section sign, best written as §.

The icon does not appear. Almost always the dimensions. Open the file and check it is 64x64, and check the startup log for the warning. A PNG exported at 64x64 with an alpha channel is what works.

"Failed to download resource pack" on the client. Fetch the URL yourself with curl -IL from another machine. In order of likelihood: it redirects to an HTML page, the certificate is invalid or expired, the host blocks the request, or the file is too large.

The pack downloads but nothing changes. The zip structure. pack.mcmeta has to be at the top level. Unzip your own file and look.

The pack updated for you and not for anyone else. Their client has the old file cached under the same URL and the same hash. Rename the file and update both properties.

The server does not appear in the list at all. That is not a MOTD problem. Check that the server is running, that the port in the client entry is the game port, and that enable-status is true. The wider version of this is in server.properties explained.

FAQ#

How long can a MOTD be?

There is no hard limit you will hit, but the client clips each of the two lines at roughly 45 characters of normal-width text, and bold characters are wider. Write for 40 and check it in the actual client rather than counting.

Can I change the MOTD without restarting?

Not from server.properties, which is read at startup. A MOTD plugin can change it live, and on Paper the reload of that specific plugin's config is usually enough. Changing the file and restarting is the reliable route.

Where exactly does server-icon.png go?

The server's root directory, next to server.properties, eula.txt and the world folder. Not in plugins/, not in the world folder. On the panel that is the top level of the file manager.

Do I need the SHA-1 hash for a resource pack?

Not to make it work, but yes in practice. Without it every player re-downloads the pack on every single join. With it, the download happens once and the client reuses its copy until the hash changes.

Why do some players join without the pack at all?

Because they have resource packs disabled for your server in their client's server entry, which auto-declines the prompt. If require-resource-pack is false they join without it and nothing tells you; if it is true they are disconnected and blame the server.