Hash Generator
Generate cryptographic hashes, or HMAC signatures for verifying webhook payloads
About this tool
The ToolNinja Hash Generator is a free online hash calculator supporting SHA-1, SHA-256, SHA-384, SHA-512, and HMAC signatures. Enter any text and instantly generate its hash value — useful for checksums, data integrity verification, and webhook signature verification. Use the SHA-256 generator for data integrity verification and digital signatures, or SHA-512 when you need maximum hash length. All hashing runs using the Web Crypto API built into your browser for accurate, standard-compliant results. Common use cases include verifying downloaded file integrity by comparing checksums, generating content hashes for cache busting in web development, creating hash-based identifiers, and understanding how different algorithms compare in output length and security properties. A File mode hashes an uploaded file directly — drag it in and get its checksum without needing a command-line tool, useful for verifying a download against a publisher's published SHA-256 sum. The file itself is read and hashed entirely in your browser and never uploaded anywhere. Once a hash or HMAC is computed, a Verify field lets you paste the value you're checking against — a webhook's signature header, a publisher's published checksum — and get an immediate match/mismatch result using a constant-time comparison, the same property real signature-verification code needs to avoid leaking timing information. Everything runs 100% in your browser. Your input data — no matter how sensitive — never leaves your machine. No login required.
When to use it
- →Verifying file integrity by comparing checksums before and after transfer
- →Generating content-based cache keys for assets or API responses
- →Creating deterministic identifiers from arbitrary string inputs
- →Understanding what algorithm produced a stored hash
- →Computing an HMAC signature to verify a webhook payload from Stripe, GitHub, or similar services
- →Checking a downloaded file against a publisher's published checksum without a command-line tool
Tips
- ◆SHA-1 is cryptographically broken — don't use it for security. SHA-256 is the current standard for general-purpose integrity checks.
- ◆Two different inputs that produce the same hash are called a collision. SHA-256 and SHA-512 have no known practical collisions.
- ◆Hashing is not encryption — you cannot recover the original input. Use it for integrity, not confidentiality.
- ◆Switch to HMAC mode and paste the raw request body plus your webhook secret to verify a Stripe/GitHub signature header matches — compare the result byte-for-byte, not just visually.
- ◆Use File mode to verify a download's checksum directly — no need to open a terminal for a one-off sha256sum check.
- ◆Use the Verify field instead of eyeballing two hex strings — a constant-time comparison catches a mismatch reliably, and it automatically strips a leading sha256= prefix some providers (like GitHub) include in their signature header.
Frequently asked questions
What is the difference between SHA-256 and SHA-512?
SHA-256 produces a 256-bit (64 hex character) hash and is the most widely used hash function. SHA-512 produces a 512-bit (128 hex character) hash and offers a larger security margin. For most applications SHA-256 is sufficient. SHA-512 can be faster on 64-bit processors for large inputs due to its 64-bit word size.
Can I reverse a hash back to the original input?
No. Cryptographic hash functions are one-way — they are specifically designed to be computationally infeasible to reverse. The only practical attack is a brute-force or dictionary search, which is why short or common inputs (like simple passwords) can sometimes be looked up in rainbow tables.
Is SHA-256 the same as HMAC-SHA256?
No. SHA-256 is a plain hash function — given the same input, anyone gets the same output. HMAC-SHA256 is a keyed message authentication code that incorporates a secret key into the hash. HMAC output depends on both the message and the key, so only parties with the key can verify the hash. JWT uses HMAC-SHA256 for signature generation.
Is MD5 safe to use?
For checksums, yes: verifying a download matches a published MD5 or deduplicating files is fine. For security, no. Practical collision attacks exist, meaning two different inputs can be crafted to produce the same hash, so never use MD5 for passwords, signatures, or integrity checks against an attacker. SHA-256 is the correct replacement there. MD5 is computed by a built-in implementation, since the browser's Web Crypto API deliberately leaves it out.
Why does the Verify field use a 'constant-time comparison' instead of just checking if the strings are equal?
A plain string comparison (like ===) typically stops at the first character that doesn't match, so it takes slightly less time to reject a hash that's wrong in the first character than one that's wrong in the last. In theory, an attacker who can measure that timing precisely enough could exploit it to guess a valid signature one byte at a time. A constant-time comparison always checks every character regardless of where a mismatch occurs, so the comparison time doesn't leak any information about how close a guess was.