Set up a Minecraft resource pack on the serverYour own look for all players - loaded automatically

Published on October 20, 2026

How the mechanism works

Important for understanding: the Minecraft server does not host the pack. When connecting, it only tells the client two things - a URL where the file is located and, optionally, a checksum. The client then downloads the pack itself.

It follows that you need a place where the .zip file can be reached via a direct link. It is not enough to put it on the game server - its files cannot be retrieved via HTTP.

Any place that provides an unchanging direct link is suitable, such as web hosting. Share links that lead to a preview page instead of directly to the file are unsuitable.

For context: a datapack works purely on the server and lives in its world folder; a resource pack is purely a client matter. And the server icon, in turn, is a single file in the server directory. Three things that are easily mixed up because they all "somehow affect the look".

The right place for the file

You can check in half a minute whether a URL is suitable: open it in a private browser window. If the download of the .zip starts immediately, the link is usable. If a page with a preview, login or waiting notice appears instead, the Minecraft client gets exactly that page delivered - and reports a broken pack.

• HTTPS and a fixed path. No redirect chains and no links that expire after a few days.
• File name without spaces or special characters. That saves encoding problems in the configuration line.
• Permanently reachable. If the location disappears, new players see the default look - with require-resource-pack=true, they do not get in at all.
• Versioned file name. pack-v4.zip instead of pack.zip makes every update unambiguous and bypasses old caches.

Web hosting meets all of this and is in the same hands as the server. The game server itself is out of the question: you reach its files via SFTP and the WebFTP file manager, but not via HTTP - at the fixed server address made of IP and port, only Minecraft is listening, not a web server.

Entries in server.properties

Three values control the behaviour - all in server.properties:

resource-pack=https://example.com/pack.zip
resource-pack-sha1=<SHA-1-checksum>
require-resource-pack=false

• resource-pack - the direct link to the ZIP file.
• resource-pack-sha1 - the file's checksum. Without it, the client downloads the pack again on every connection.
• require-resource-pack - with true, the pack becomes mandatory; whoever declines does not get onto the server.

A restart is needed after changes. You determine the checksum locally with a SHA-1 tool - on Windows, for example, via certutil -hashfile pack.zip SHA1, on Linux and macOS via sha1sum pack.zip or shasum pack.zip.

Renew the checksum with every update

By far the most common error during operation: the pack is updated, the SHA-1 stays the same.

The consequence is treacherous - players keep getting the old, cached version, or loading fails because file and checksum do not match. Both look like a broken pack, but it is just an outdated hash.

• After every change to the pack, recalculate the SHA-1 and enter it.
• Alternatively, store the file under a new name and adjust the URL - then no old cache applies.

Mandatory or optional?

The decision about require-resource-pack has noticeable consequences:

Mandatory makes sense if the pack carries game content - such as custom item models without which a server concept does not work. For pure texture packs, optional is the friendlier choice. Keep the pack small: every megabyte is waiting time on the first connection.

What players see when something is stuck

The server tells you little, because loading happens on the player's side. All the more helpful to know the view from there:

• Prompt when connecting. The client asks whether the pack should be loaded. Whoever declines keeps playing with the default look - or is rejected if the pack is mandatory.
• Failed download. The player still lands on the server but sees the normal textures. This is exactly why a broken link often goes unnoticed for days - except by the players who wonder about missing custom models and think it is an error on their side.
• Long hang when joining. Very large packs stall the connection. For players, this cannot be told apart from a connection error.
• Bedrock players are left out. Whoever joins via crossplay usually does not get to see a Java resource pack - the Bedrock Edition uses its own pack format. So do not plan your server in a way that makes it unplayable without the custom look as long as Bedrock players are supposed to join.

The only reliable test is from the player's perspective: connect with a second account and a cleared cache. If the pack appears there, it appears for everyone else too. Check how long the download takes while you are at it - what takes two seconds for you can mean half a minute of waiting elsewhere before the first gameplay.

Common mistakes

• No direct link - the URL leads to a preview page instead of the file. The client cannot do anything with it.
• No HTTPS - unencrypted links cause problems depending on the environment.
• Outdated SHA-1 - the classic after a pack update.
• Wrong pack_format number in pack.mcmeta - then the client reports the pack as incompatible.
• Pack too large - very large packs make the connection run into nothing.

To test, connect yourself once with a cleared client cache - that way, you see exactly what a new player sees.

Frequently asked questions