A server can hand every player a resource pack when they join. Almost none do, and the ones that do frequently do it badly enough that players turn it off.
Done well it is the cheapest way to give a server an identity. Done badly it is an eight-second download that annoys everyone.
How it works
Three lines in server.properties: the pack URL, a SHA-1 hash of the file, and whether the pack is required.
The server sends those to the client on join. The client downloads the pack from the URL, checks it against the hash, and either applies it or – if required is set – disconnects the player who declines.
The hash is not optional in practice. Without it, clients cache aggressively and a pack you updated will not reach people who already joined once. Every pack change needs a new hash, and forgetting that is the most common reason “the new pack is not showing up”.
Required, or optional
The single most consequential setting, and the default answer is optional.
Required means a player who declines cannot join. That is correct for a server where the pack carries information – custom item models that indicate function, a map where textures are part of the puzzle – and wrong for almost everything else.
Optional means a player who declines plays with vanilla textures. On a survival server where the pack is atmosphere rather than information, that is fine, and it avoids losing players who have their own pack they prefer.
The test: can a player who declined the pack still understand what they are looking at? If yes, optional.
Hosting the file
The URL has to be a direct link to the file, reachable by every player, and stable. Three practical options.
- Your own web host. Simplest if you have one. A static file on the same domain as your site.
- Object storage. S3-compatible storage with a public URL. Cheap and it does not go down when your server does.
- A file host that serves direct links. Workable, with the caveat that free hosts change URLs and add interstitials, both of which break the pack silently.
What does not work is a link to a download page rather than a file, which is the failure mode of most general file-sharing services.
Size matters more than people expect. Every player downloads it once per version, and a 200MB pack on join is a bad first impression. Under 20MB is comfortable; over 100MB needs a reason.
What to put in it
The temptation is a full texture pack. The better answer for most servers is a small pack that does specific jobs.
- A server logo on the pack icon and in the menu.
- Custom item models for anything the server treats specially – a plugin item, a rank token, an event reward.
- Readability fixes, the same category as the quality-of-life packs, applied server-wide so everyone benefits.
- Sound changes for server events, which are cheap and memorable.
What to avoid is anything that fights a player’s own preferences. A server pack that replaces every block texture takes away a choice players care about, and it is the main reason people decline packs.
The version problem
Pack format numbers change with the game. A pack built for 26.2 will warn on 26.3 and may fail outright, and 26.4 moves the resource pack version to 98.0.
That makes the server pack one more thing on the version migration checklist, and it is the item most often forgotten, because a failing pack does not stop the server starting – it just quietly does not apply.
The fix is to test with an actual client after every version bump, not to assume.
A working setup
- Build a small pack that does two or three specific things.
- Host it somewhere stable with a direct file URL.
- Generate the SHA-1 hash and put it in server.properties. Regenerate it every time the file changes.
- Leave required off unless the pack carries information.
- Test by joining with a fresh client profile, not with your own.
- Re-test after every game version update.
Step five catches the caching problems that step three is supposed to prevent, and it is worth the two minutes. Everything here is small enough to sit alongside the rest of a server’s setup rather than being a project of its own.
What players see
The prompt on join is short, and players make a decision in about two seconds based on it.
That decision is influenced by one thing you control: whether they trust the server. A server with a recognisable name and a pack they were told about in advance gets accepted. An unexpected pack prompt from a server someone just found gets declined.
So the pack is worth mentioning in the server description and on whatever page people find the server through. Two sentences of warning converts more acceptances than anything in the pack itself.
Testing the failure cases
Three things to verify before trusting it, and all three fail silently.
- The URL from outside your network. A host that resolves locally and not publicly is a classic.
- The hash. Change the file, forget the hash, and returning players keep the old pack indefinitely.
- Behaviour on decline. With required off, a declining player should still be able to play normally. Test it rather than assuming.
The third is the one nobody checks, and it is the one that produces a confusing bug report months later.
Images: Icons project gallery.