Verifying Plugin Downloads and Checksums for Minecraft Servers

Answer: compare the SHA-256 hash with the publisher's value

Verify a plugin download by computing its SHA-256 hash and comparing it with the value the publisher posted for that exact version. A match shows the file is the one the publisher released. It does not prove the publisher is trustworthy, so buy and download from the official source first, then check the hash. Record the hash with the version in your change log.

Get the expected hash from the publisher

Open the publisher's download page or release notes for the exact version you plan to deploy. Copy the SHA-256 value. If the publisher does not post hashes, ask for one before deployment and write down the answer.

Compute the hash on the server

Run the command from the server root, against the jar in the plugins folder. Replace the placeholders with your plugin name and version.

• Compare the printed hash with the publisher's value character by character, or with a diff tool.
• Do not accept a hash pasted into chat unless you have matched it to the official page yourself.

# Linux server, run from the server root
sha256sum plugins/<PluginName>-<version>.jar

# macOS alternative
shasum -a 256 plugins/<PluginName>-<version>.jar

Decide what the result means

A hash check has four possible outcomes. Each one needs a different next step, and none of them should be skipped.

Inspect the jar before it loads

A matching hash confirms the file, but you still need to confirm what the file says it is. These checks take a few minutes and catch a wrong jar or a mismatched build early.

• Confirm plugin.yml names the plugin and version you expect.
• Check that the api-version in plugin.yml matches the Minecraft line you run. Note any mismatch and resolve it before loading.
• Look for unexpected nested jars or unfamiliar file names, and escalate them instead of loading the file.

# List the top-level entries of the jar
unzip -l plugins/<PluginName>-<version>.jar | head -n 20

# Print the plugin descriptor
unzip -p plugins/<PluginName>-<version>.jar plugin.yml

Pin versions and record every file

Pin each plugin to one version. Turn off automatic updates in any tool that replaces jars for you. A pinned version lets you reproduce an alert or an appeal later, because you know exactly which build produced it.

• Write the plugin name, version, hash, source URL, and date in the change log.
• Keep the verified jar in a versioned folder so a rollback uses the same bytes.
• Repeat the check on every server that loads the plugin, including proxy and lobby servers, and compare hashes across them.

What the hash does not prove

A checksum proves that two files match. It does not prove the plugin has no bugs, and it does not prove the publisher's site was never compromised. If an attacker controls the download page, they can post a matching bad hash. Check the hash against the seller's listing as well as the developer page, and watch for differences between them.

Also remember that a verified jar can still be configured badly. Verification and configuration review are separate steps.

The hash also says nothing about your config files. Those change independently of the jar, so track them through your change log and review process rather than through the publisher.

What we have not verified

We have not confirmed that every vendor publishes SHA-256 hashes, and this page does not assume they do. We have not tested the commands on every operating system or hosting panel. Confirm the command output on your own host before you write it into a runbook.