Hash Generator & Checksum Tool

What is hashing?

Hashing is the process of running arbitrary data through a mathematical function that produces a fixed-length output called a hash, digest, or checksum. The same input always produces the same output; a tiny change in the input (one character, one bit) produces a completely different output. Crucially, the process is one-way: you can compute a hash from data, but you cannot compute the data back from its hash.

Hashing shows up everywhere in software: verifying downloaded files, detecting accidental corruption, storing passwords (with a specialised KDF), signing commits in git, fingerprinting API payloads, deduplicating storage, and building search indexes. Every developer needs a reliable way to compute a hash without opening a terminal — this tool does that entirely in the browser.

How hash functions work

A cryptographic hash function takes an input of any size and produces a fixed-size output. SHA-256, for example, always returns 256 bits (32 bytes, 64 hex characters) whether the input is one byte or one gigabyte. The function is designed so that:

• Deterministic: the same input always produces the same hash.
• Fast to compute: hashing a gigabyte takes a fraction of a second.
• Infeasible to reverse: given only a hash, you cannot reconstruct the input.
• Collision-resistant: finding two different inputs with the same hash should be computationally impractical.
• Avalanche effect: changing a single bit of input changes roughly half the output bits.

The browser's Web Crypto API exposes SHA-1, SHA-256, SHA-384, and SHA-512 through crypto.subtle.digest(). MD5 is not part of that API (it's considered broken for security purposes), so this tool ships a compact, self-contained, byte-correct MD5 implementation for legacy compatibility.

What is SHA-256?

SHA-256 is a member of the SHA-2 family, standardised by NIST in 2001. It produces a 256-bit digest, written as 64 hexadecimal characters. It's the default hash for TLS certificates, Bitcoin block headers, JWT signatures (HS256), git object storage, and virtually every modern integrity check. No practical collision or preimage attack against SHA-256 is known.

Example — hashing Hello World with SHA-256:

Input:  Hello World
SHA-256: a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

What is SHA-512?

SHA-512 is also a SHA-2 family member, but produces a 512-bit digest (128 hex characters). It's slower than SHA-256 on 32-bit CPUs, faster on 64-bit CPUs, and its longer output makes brute-force collision attacks even harder. It's used in some password-hashing constructions (as the underlying primitive for SHA-512-crypt), in Ed25519 signatures, and by systems that want a wider digest for extra safety margin.

SHA-384 sits between them: 384 bits (96 hex characters). It uses the same compression function as SHA-512 but with different initial values, giving a shorter digest that's still well above any practical attack threshold.

SHA-256 vs SHA-512

Both are recommended. The practical differences are:

• Digest size: SHA-256 = 32 bytes, SHA-512 = 64 bytes. SHA-512's larger output is overkill for most integrity checks.
• Speed: SHA-512 is faster on 64-bit hardware (which is everything today) because its internal word size is 64 bits rather than 32.
• Interoperability: SHA-256 is far more widely supported by tools, libraries, and services. When in doubt, choose SHA-256.
• Attack margin: SHA-512 offers a longer safety margin against future cryptanalysis, but the practical difference is negligible for the next several decades.

For checksums and file verification, SHA-256 is the right default. Use SHA-512 when a specification demands it or when you want the longest digest available.

MD5 and SHA-1 — legacy only

Both MD5 and SHA-1 are broken for cryptographic purposes. MD5 has practical collision attacks that can be computed on a laptop in seconds; SHA-1's collisions are also practical (the SHAttered attack demonstrated two PDFs with the same SHA-1 in 2017). Neither is safe for signature verification, certificate generation, or any scenario where an attacker could choose the input.

They still have legitimate uses:

• MD5: verifying that a downloaded file is intact (not malicious — just complete), matching legacy checksums published by old software, computing Content-MD5 headers that S3 and other services accept, and non-security hashing such as caching keys.
• SHA-1: git commit identifiers, legacy checksum files, existing signed documents you need to verify, and hash tables where security is irrelevant.

This tool labels both as legacy — not for cryptographic security. Do not use them for new security work.

Hash vs encryption

These are often confused, and the difference matters:

• Hashing is one-way: data → hash. There is no key. You cannot recover the data from the hash. The output is fixed-length regardless of input length.
• Encryption is two-way: plaintext ⇄ ciphertext. It requires a key. With the key, you can recover the plaintext exactly. The output length matches the input length (modulo block padding).

A hash is a fingerprint, not a vault. If you hash a password, you don't "decrypt" it later — you hash the input again and compare the two digests. That's why password storage relies on slow, salted KDFs (Argon2, bcrypt, scrypt, PBKDF2) rather than raw SHA-256: the KDF makes brute-force guessing expensive, while a raw hash is designed to be fast.

Hash vs encoding

Encoding (Base64, URL encoding, hex) is reversible without a key. It exists to move data through channels that can't carry arbitrary bytes. Hashing is irreversible by design. Base64-encoded data can always be decoded back to the original bytes — no secret required. Hashed data can never be reversed; that's the whole point.

If you see someone use the words "encrypt" and "Base64-encode" interchangeably, they're confused. If they say "hash" and "encode" are the same, they're wrong. This tool hashes; for Base64, use the Base64 Encoder & Decoder.

What is a checksum?

"Checksum" is an informal name for a hash used to verify integrity — usually of a file. When you download software, the release page often lists SHA-256 checksums. You compute the hash of the file you downloaded and compare it against the published value. If they match, the bytes arrived intact.

A checksum match confirms integrity, not authenticity. If the published checksum itself came from an attacker (e.g. a compromised download page), the file could be malicious and still match the checksum you were given. For real authenticity, use a cryptographic signature (GPG, Sigstore, or similar) that's verified against a trusted key.

How file hashing works

A file is just a byte stream. To hash it, you feed those bytes into the hash function — exactly the same function you'd use for text. Two files with the same content produce the same hash regardless of filename, timestamp, or filesystem metadata.

The Web Crypto API's crypto.subtle.digest() requires the full input to be available in memory. That's fine for files up to hundreds of megabytes in a modern browser, but it does mean very large files (>1 GB on memory-constrained devices) can hit browser limits. This tool reads the file into an ArrayBuffer, hashes it, and releases the buffer afterwards. If a file is too large to handle comfortably, you'll see a clear warning rather than a silent hang.

How text hashing works (and UTF-8)

Text hashing has one subtlety: a string is not a byte sequence until you decide on an encoding. This tool always encodes text to UTF-8 via TextEncoder before hashing, which matches how virtually every server-side and native implementation handles string input.

Example — Hello नमस्ते 👋 世界 contains 20 characters in JavaScript's internal representation but 37 UTF-8 bytes. The SHA-256 of the string is computed over those 37 bytes. If you hashed the string as Latin-1 or UTF-16 bytes, you'd get a different digest — that's why the tool reports character count and UTF-8 byte count separately.

Hash collisions

A collision is when two different inputs produce the same hash. Cryptographically strong hashes are designed to make collisions infeasible to find — SHA-256 has no known collisions. Weak hashes have practical collisions: MD5 collisions can be computed in seconds, and SHA-1 collisions were demonstrated in 2017.

The birthday paradox gives the expected number of hashes you'd need to compute before a 50% chance of any collision: about 2^n/2 for an n-bit hash. For SHA-256 that's roughly 2¹²⁸ — trillions of trillions of hashes. For MD5 it's roughly 2⁶⁴, which is why chosen-prefix collisions are practical on modern hardware.

How developers use hashes

• Verify downloaded files: compare a computed SHA-256 against the publisher's checksum.
• Compare build artifacts: hash release binaries to detect drift between environments.
• Content-addressed storage: name files by their SHA-256 (git does this internally).
• Fingerprint API payloads: hash a JSON body to detect duplicate requests or build ETags.
• Detect accidental changes: cache a hash of a config file and warn when it changes unexpectedly.
• Cache keys: hash a URL plus parameters into a fixed-length key for a cache store.
• CI/CD: verify artifact integrity across pipeline stages with SHA-256.
• Sign and verify: HMACs and digital signatures are built on hash functions.

Common hashing mistakes

• Storing passwords with MD5 or SHA-256. Fast hashes are the wrong tool. Use Argon2 or bcrypt.
• Forgetting to salt password hashes. Without a salt, identical passwords produce identical hashes, enabling rainbow tables.
• Comparing hashes with a normal string equality check. That leaks timing information; use constant-time comparison for secrets.
• Trusting a checksum from an untrusted source. A matching checksum only means the file matches that checksum — not that the file is safe.
• Assuming UTF-8 vs UTF-16 doesn't matter. It does — the same string hashes differently depending on encoding.
• Using SHA-1 for new signatures. Don't. Use SHA-256 or stronger.
• Truncating digests casually. A truncated hash has reduced collision resistance; know the trade-off before doing it.

Privacy and security

Everything on this page runs locally in your browser. Text, files, and hash results never leave the page — there is no server request, no logging, and no analytics on your content. The Web Crypto API and the MD5 implementation are both pure client-side.

The tool never uploads files, never logs input, and does not retain data after you close the tab. You can safely hash production binaries, private keys (as data, not as an endorsement), internal documents, and customer payloads without worrying about exfiltration.

Related developer tools

• API Request Builder — send HTTP requests and hash response bodies for integrity checks.
• JSON Diff — see exactly which fields changed between two payloads, not just that they differ.
• Base64 Encoder & Decoder — decode hash values that have been Base64-encoded for transport.
• UUID Generator & Validator — create random IDs to pair with hashes in fixtures and test data.
• JWT Debugger — inspect tokens whose signatures are computed over hash digests.
• Regex Tester & Debugger — extract hash-like strings from logs and text.
• Universal Data Transformer — convert hash lists into JSON, CSV, YAML, or SQL.
• JSON vs XML comparison guide — background on data-format choices for APIs.

Frequently asked questions

What is a hash?

A fixed-length fingerprint produced by a one-way function. The same input always produces the same hash; the hash cannot be reversed back to the input.

What is SHA-256?

A widely used 256-bit cryptographic hash from the SHA-2 family. It produces a 64-character hex digest and is the default hash for TLS, Bitcoin, and most modern integrity checks.

What is SHA-512?

The 512-bit variant of SHA-2. It produces a 128-character hex digest. Faster than SHA-256 on 64-bit CPUs and offers a longer safety margin.

What is the difference between SHA-256 and SHA-512?

Digest size (32 vs 64 bytes) and speed on 64-bit hardware. Both are cryptographically secure; SHA-256 is more widely interoperable, so it's the safer default.

What is MD5?

A 128-bit hash from 1991. It's fast and widely available but cryptographically broken — collisions are trivially computable. Useful for non-security checksums, not for signatures or passwords.

Is MD5 secure?

No. Chosen-prefix collisions on MD5 can be computed in seconds on consumer hardware. Do not use MD5 for any new security purpose.

Is SHA-1 secure?

No, not for new security work. Practical SHA-1 collisions were demonstrated in 2017. SHA-1 survives in legacy contexts (git IDs, old checksums) but should not be chosen for new signatures.

What is a checksum?

A hash used to verify data integrity. Published checksums let you confirm a downloaded file arrived complete and unmodified.

How do I verify a downloaded file?

Get the publisher's SHA-256 checksum, select the file in this tool, run SHA-256, and paste the expected checksum into the compare box. A match means the bytes are intact relative to that checksum.

Can I hash a file?

Yes — drop any file into the File Hash section. Files are read locally and hashed in your browser. No uploads.

Can I hash Unicode text?

Yes. Text is encoded to UTF-8 bytes before hashing, matching server-side implementations. Emojis, Hindi, Chinese, and mixed Unicode all hash correctly.

Does this tool upload my files?

No. All hashing runs in your browser using Web Crypto and a local MD5 implementation. Nothing is transmitted anywhere.

Is hashing the same as encryption?

No. Hashing is one-way and keyless; encryption is reversible with a key. Hashing produces a fixed-size fingerprint; encryption preserves the length of the plaintext.

Can a hash be reversed?

Not practically. You can attempt brute force or rainbow-table lookup against short or common inputs, but cryptographic hashes are designed to make reversal infeasible.

Can I use SHA-256 for passwords?

No. SHA-256 is designed to be fast, which makes brute-force attacks cheap. Use a dedicated password KDF — Argon2id, bcrypt, scrypt, or PBKDF2 — with a per-user salt and a work factor tuned to your hardware.