Free Hash Generator

Generate cryptographic hash values for any text using SHA-256, SHA-384, and SHA-512. Runs in your browser using the Web Crypto API — no data sent to any server.

Enter your details
Result
Enter your details on the left, then press Calculate.

What is this calculator for?

You downloaded a 1.2 GB installer from a website. The download page lists an SHA-256 checksum. You want to verify your downloaded file hasn't been corrupted or tampered with. Or you're building authentication for an app and need to hash user passwords before storing. The hash generator computes cryptographic hashes (MD5, SHA-1, SHA-256, SHA-512) of text input.

Hash functions explained. A hash function takes any input and produces a fixed-size output (the "hash" or "digest"). Same input always produces same output; different inputs (with overwhelming probability) produce different outputs. Hash functions are one-way: you can't reverse a hash to recover the input. Used for: file integrity verification (download checksums), password storage (compare hashes, never store plaintext), digital signatures, blockchain (Bitcoin's proof-of-work uses SHA-256), data deduplication, content-addressable storage.

This tool computes common cryptographic hashes from text input. For file hashing: use command-line tools (sha256sum on Linux, certutil on Windows, openssl on Mac) which handle large files efficiently.

How to use this calculator

Paste text into the input. Pick the hash algorithm: MD5 (legacy, broken for security), SHA-1 (deprecated but still common), SHA-256 (standard), SHA-512 (longer output, same security as SHA-256 in practice).

The tool outputs the hash in hex format. Sample for input "Hello, World!": MD5 = 65a8e27d8879283831b664bd8b7f0ad4. SHA-256 = dffd6021bb2bd5b0af676290809ec3a53191dd81c7f70a4b28688a362182986f.

For verification: compare your computed hash to the published checksum. Identical hash = file is intact. Different hash = file is corrupt or tampered.

Understanding your results

The tool outputs hashes in hex format (lowercase or uppercase as configured).

Hash algorithm comparison. MD5: 128-bit output (32 hex chars). Cryptographically broken since 2008 — collisions can be generated rapidly. Still used for non-security purposes (file integrity checking where adversary isn't a concern, deduplication). Should NEVER be used for password storage or digital signatures. SHA-1: 160-bit (40 hex chars). Practically broken (Google demonstrated collision in 2017). Deprecated by NIST in 2011 but still encountered in legacy systems. Don't use for new security applications. SHA-256: 256-bit (64 hex chars). Currently secure; standard for new applications. Used in Bitcoin, TLS certificates, software signing, government cryptographic standards. SHA-512: 512-bit (128 hex chars). Functionally equivalent security to SHA-256; faster on 64-bit systems. Less common but used in some contexts (Argon2 password hashing uses BLAKE2 or SHA-512 as underlying primitive).

Password hashing reality. NEVER store passwords as plain hashes (even SHA-256). Reason: rainbow tables and brute force can crack common passwords in seconds. For password storage: use bcrypt, scrypt, or Argon2 — algorithms specifically designed to be slow and salted. These can't be computed with this hash tool; require server-side libraries. SHA-256 is fine for file integrity, content addressing, signatures — NOT for password storage.

File integrity workflow. Software publisher uploads installer and computes SHA-256 hash. Publishes the hash on download page. User downloads installer, computes SHA-256 locally, compares to published hash. Match = file is intact and unmodified. No match = file is corrupted or tampered. Note: this only protects against tampering during download; it doesn't protect against malicious publishers who could control both the file and the published hash. For high-security verification: use GPG signatures with verified publisher keys.

Hash collisions. A "collision" is when two different inputs produce the same hash. For a good hash function: collisions exist mathematically but are computationally infeasible to find. MD5: collisions can be found in milliseconds. SHA-1: collisions found in days of computation. SHA-256: no practical collision found; would require more computation than has ever existed. The collision question matters for: malware detection (can attacker produce a malicious file with same hash as legitimate file?), digital signatures (same), Bitcoin (collisions would enable double-spending).

A worked example

A user downloads Ubuntu 24.04 LTS ISO (4.7 GB). The Ubuntu download page lists SHA-256 hash for verification: 3e44f8a9d3a4ba7f08e76fbc6f80a4e15....

User runs SHA-256 calculation on their downloaded file. Linux: sha256sum ubuntu-24.04-desktop-amd64.iso. Windows: certutil -hashfile ubuntu-24.04-desktop-amd64.iso SHA256. Mac: shasum -a 256 ubuntu-24.04-desktop-amd64.iso.

Output matches published hash: file is intact. Install confidently.

Alternate outcome: hash doesn't match. Several possibilities. (1) Download was corrupted in transit — re-download. (2) Wrong file (downloaded different version). (3) File was tampered with by a man-in-the-middle attack. In all cases: don't install the file; re-download from official source.

Variation: web developer adding password verification to a side project. INCORRECT approach: SHA-256 hash the password, store hash in database, compare hashes on login. Problem: this is vulnerable to rainbow tables. Attacker who gets the database can crack common passwords ("password123", "letmein", etc.) within seconds using precomputed rainbow tables of hash values.

CORRECT approach: use bcrypt (or Argon2). bcrypt.hash(password, 12) — the 12 is a cost factor that makes hashing intentionally slow (about 250ms on modern hardware). Each password also gets a unique random salt incorporated into the hash. Result: rainbow tables don't work; brute force is computationally prohibitive. To verify login: bcrypt.compare(submittedPassword, storedHash). The library handles salt and slow-hashing internally.

Related resources

For other encoding/decoding tools, see Base64 and URL Encoder. For random data generation (also security-relevant), the Password Generator and Random Number Generator. The NIST Hash Function project publishes US federal standards for hash algorithms; OpenSSL is the primary library used for hash computation in software systems.

Related calculators

base64url encoderpassword generator

Frequently asked questions

What is a hash?

A hash function takes any input and produces a fixed-length output (the hash or digest). Good hash functions are deterministic (same input always gives same output), fast to compute, and collision-resistant (two different inputs extremely unlikely to produce the same hash). They are one-way — you cannot reverse a hash back to the original input.

What is the difference between SHA-256 and MD5?

SHA-256 (SHA-2 family) produces a 256-bit hash and is considered cryptographically secure. MD5 produces a 128-bit hash but is broken — collision attacks are practical (two different files can be crafted with the same MD5). MD5 is still used for non-security file integrity checks but must never be used for password hashing or digital signatures. The Web Crypto API excludes MD5 due to its insecurity.

Is hashing the same as encryption?

No. Hashing is one-way — you cannot recover the original input from a hash. Encryption is two-way — you can encrypt and later decrypt with the right key. Use hashing to verify integrity or to store passwords (use bcrypt or Argon2, which are deliberately slow, rather than SHA for passwords). Use encryption when you need to recover the original data later.

Which hash algorithm should I use?

Depends on purpose. File integrity verification: SHA-256 (industry standard, fast, secure). Password storage: bcrypt, scrypt, or Argon2 — NOT direct hashes. Digital signatures: SHA-256 or SHA-512 (whatever the signature scheme requires). Content addressing (blockchain, IPFS): SHA-256 standard. Old systems may need MD5 or SHA-1 for compatibility — fine for non-security uses but not appropriate for new security applications. Legacy MD5 and SHA-1: deprecated for security; still acceptable for non-adversarial integrity checking (deduplication, basic file verification when threat model is corruption not malice).

Is MD5 still safe to use?

For non-security applications: yes. Use cases where MD5 is fine: deduplicating files (checking if two files are identical), generating cache keys, distributing files to multiple locations and verifying delivery (where corruption is the concern, not malicious tampering). Use cases where MD5 is NOT safe: any security-critical context. Don't use for: digital signatures, password hashing, certificate verification, malware detection, cryptographic protocols. Cryptographic collisions in MD5 can be generated rapidly; attackers can produce two different files with the same MD5 hash.

Can two different inputs have the same hash?

Yes — called a 'collision.' For any hash function: collisions exist mathematically because the input space (all possible files) is larger than the output space (fixed-size hash). But finding collisions is intentionally hard for good hash functions. For SHA-256: no practical collision has ever been found, and would require more computation than exists. For MD5: collisions found rapidly (now within milliseconds for specific structured inputs). For SHA-1: collisions found in 2017 (the SHAttered attack). Practical implications: collisions matter for adversarial contexts (someone trying to forge signatures or pass malicious files as legitimate); they're not a concern for typical file-integrity-vs-corruption scenarios.

Should I hash passwords?

Yes, but with a special password-hashing algorithm, not direct SHA-256. Direct hashing (sha256(password)) is fast — fast enough that attackers with stolen databases can crack common passwords in seconds using rainbow tables and brute force. Password-hashing algorithms (bcrypt, scrypt, Argon2) are intentionally slow (configurable to take 100-500ms per hash) and use unique salts per password. This makes rainbow tables impossible and brute force computationally prohibitive. Industry standard as of 2024-25: Argon2id with appropriate cost parameters (memory: 64 MB, iterations: 3, parallelism: 1) for new applications; bcrypt with cost factor 12 for existing systems.

What's the difference between hashing and encryption?

Reversibility. Hashing: one-way; you can't recover the input from the hash. Encryption: two-way with a key; encrypted data can be decrypted back to plaintext given the key. Use cases: hashing for verifying data integrity, storing password equivalents, content addressing. Encryption for protecting confidentiality of data (database encryption, file encryption, network encryption). Both used together: passwords are typically hashed (you don't need to recover them, just verify them); credit card numbers are typically encrypted (you need to retrieve them for processing payments).