How to Use This Tool
- Drop or pick any file (no size limit beyond your browser’s memory)
- Copy the resulting SHA-1 hash, or paste an expected hash to verify a match
- Or switch to text mode to hash arbitrary text (UTF-8 bytes)
- Need SHA-256 or SHA-512? Use the algorithm picker. SHA-1 is the default because Minecraft and most game-server workflows expect it
Hashes are computed entirely in your browser via the Web Crypto API. Files never leave your machine.
The #1 Use Case: Minecraft resource-pack-sha1
Minecraft’s server.properties requires a SHA-1 hash that matches the file at the resource pack URL. If they don’t match, the client refuses the pack:
resource-pack=https://cdn.example.com/pack.zip
resource-pack-sha1=2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7aeRecompute every re-upload
Re-zipping a folder almost always changes the SHA-1 (timestamps, file order, compression settings all affect the bytes). Every time you upload a new pack zip, recompute the SHA-1 and update server.properties, or your players will see “Resource pack failed to load” on join.
What SHA-1 Actually Does
SHA-1 takes any number of bytes and produces a fixed 40-character hex string. Identical bytes always produce the same hash; even one bit of difference produces a totally different hash. That’s the whole point: it’s a cheap “did this file change?” signal.
It’s NOT a security signature. SHA-1 collisions are practical (Google demonstrated this in 2017), so don’t use it for tamper-resistance against motivated attackers. For game-server file-integrity checks, that doesn’t matter, the attacker has no reason to engineer a collision against a Minecraft pack.
When to Use SHA-1 vs SHA-256
| Use case | Hash to use |
|---|---|
Minecraft resource-pack-sha1 | SHA-1 (required by the protocol) |
| “Did this file change since I last looked?” | SHA-1 is fine |
| Verifying a Forge or Fabric mod download against a known list | SHA-1 for vanilla manifests, SHA-256 for CurseForge / Modrinth |
| Modpack release artifact verification | SHA-256 |
| Anything anti-tamper / cryptographic signing | SHA-256 or SHA-512 |
Common Workflows
Verify a resource pack matches your config
- Compute the SHA-1 of the local zip you’re about to upload
- Paste that into the expected hash field
- Drop the same zip back in: should show Match
- Compare to whatever’s in
resource-pack-sha1=inserver.properties. If it doesn’t match, update the config and restart the server
Check a download wasn’t corrupted
- Compute the SHA-1 of the file you downloaded
- Compare to the SHA-1 published by the source (the mod page, modpack manifest, etc.)
- Mismatch means a corrupted or tampered download
Generate a hash for any text
Switch to Text mode. Useful for hashing webhook payloads, comparing config strings, or generating a stable ID from a piece of text.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| ”Resource pack failed to load” on join | SHA-1 in server.properties doesn’t match the file at the URL | Recompute the hash on the file actually being served, paste it into resource-pack-sha1, restart the server |
| Hash differs between local and host | Host has a cached older copy, or the upload re-encoded the file | Re-upload, then verify the file on the host is byte-identical (download it back and re-hash) |
| Hash changes every time I re-zip | ZIP metadata (timestamps, file order) is different even if contents are identical | Recompute the SHA-1 every re-upload. There’s no way around this without using the same zip every time |
| Need SHA-256 or SHA-512 | Default is SHA-1 | Switch the algorithm picker above the drop zone, then re-drop the file |
Related Tools
- Minecraft Resource Pack Merger - combine multiple resource packs into one before computing the SHA-1
- Diff Checker - compare two files when their hashes don’t match
Was this tool helpful?
Frequently Asked Questions
Minecraft servers require a SHA-1 hash in server.properties (resource-pack-sha1=) so the client can verify the resource pack hasn't been tampered with mid-download. Without a matching SHA-1, players see 'Resource pack failed to load' and the pack is rejected. Vanilla servers will not start a pack download without this field set correctly.
ZIP files include timestamps and metadata that change every time the file is regenerated, even if the contents are identical. This makes the SHA-1 different. The fix is the workflow itself: every time you re-upload the pack zip, recompute the SHA-1 and update server.properties before restarting the server.
SHA-1 is broken for cryptographic signatures (collisions are practical) but it's fine for file-integrity checks where there's no attacker incentive. Minecraft uses it because it's fast and the threat model is 'detect a corrupted download', not 'detect a malicious tampering'. For modpack or release artifacts where supply-chain risk matters, use SHA-256 or SHA-512 instead.
Three usual culprits: (1) the host is hashing a cached older version of the file, (2) line endings changed when the file was edited (CRLF vs LF), or (3) the file was modified by an upload process that re-encoded it. Recompute locally with this tool and compare. The local hash on the file you're about to upload is the source of truth.
Yes. Use the algorithm picker to switch between SHA-1, SHA-256, and SHA-512. SHA-1 is the default because that's what Minecraft, Forge, and most game-server workflows use. SHA-256 is what Thunderstore (Valheim, V Rising mods) and modpack manifests typically publish. SHA-512 covers Modrinth's stronger hash. MD5 is not supported, the Web Crypto API doesn't include it.
Free forever. No signup required. Just tools that work.