Online Hash Generator

Q: Which hash should I use for file integrity?

SHA-256 is the standard choice and what almost every Linux distro, GitHub release, and Docker registry publishes. It's hardware-accelerated on most x86-64 and ARM64 CPUs via SHA-NI / ARMv8 cryptographic extensions. If you control both ends of the pipeline and care about raw throughput on large files, BLAKE3 is roughly 5-10x faster on multi-core CPUs because its internal Merkle-tree structure parallelizes naturally — but it isn't FIPS-approved, so it's a poor fit for regulated environments.

Q: Is hashing the same as encryption?

No. Hashing is one-way and produces a fixed-length digest — there is no key, and you cannot recover the input from the hash. Encryption is two-way: a key transforms plaintext into ciphertext, and the same key (symmetric) or matching key (asymmetric) recovers the plaintext. Hashes prove integrity ("this file hasn't changed"); encryption provides confidentiality ("only the recipient can read this"). The two are often combined — for example, a signed JWT contains an encoded payload plus a SHA-256-based signature; you can inspect the payload with our JWT decoder. For converting digests between bases (hex to binary or decimal), use the number base converter.

Create MD5, SHA-1, SHA-256, and SHA-512 hashes instantly to verify data integrity from text you paste.

How to Generate a Hash Online

Pick Text or File: Use the Text tab to type or paste a string, or switch to File to load a local file. The browser reads the bytes directly — nothing is uploaded.
Select Algorithm(s): Choose MD5, SHA-1, SHA-256, or SHA-512. You can select multiple and compute all of them in one pass to compare digests side-by-side.
Inspect the Digest: Each hash appears as a fixed-length hexadecimal string — 32 chars for MD5, 40 for SHA-1, 64 for SHA-256, 128 for SHA-512. The output updates instantly as you type.
Copy and Verify: Click any digest to copy it to your clipboard, then paste it into sha256sum --check, Get-FileHash, your release notes, or wherever you need to compare. Use Clear to reset.

Why Generate a Hash?

A cryptographic hash is a deterministic, fixed-length fingerprint of any input. Hashes are one-way (you cannot reverse the digest back to the data), avalanche (a one-bit change flips roughly half the output bits), and collision-resistant for secure algorithms (it is computationally infeasible to find two inputs that produce the same digest). That combination underpins most of modern data integrity, authentication, and content addressing.

Verify a downloaded file — Linux ISO releases, Docker images, and GitHub release artifacts publish a SHA-256 alongside the download. After fetching, compute the hash locally and compare; a single bit of corruption or tampering flips the entire digest.
Detect changes in source or config — Git stores every commit, tree, and blob keyed by its SHA-1 (transitioning to SHA-256). git diff, git fsck, and content-addressable backups like restic and BorgBackup all rely on hashes to spot what actually changed.
Build cache-busting asset URLs — front-end bundlers (Webpack, Vite, Rollup) append a short content hash to filenames like app.3a7b2c.js so browsers re-fetch only files whose bytes changed, while everything else stays cached.
De-duplicate storage — backup tools, container registries (Docker, OCI), and IPFS chunk data and key each block by its hash, storing identical blocks once. SHA-256 is the default; BLAKE3 is gaining traction where throughput matters.
Power digital signatures and certificates — RSA, ECDSA, and Ed25519 signatures all sign the hash of the message, not the message itself. TLS certificates, code-signing pipelines, and PDF signatures all rely on SHA-256 (sometimes SHA-384) as the hash component.
Generate deterministic IDs — content-addressable IDs in databases, dedup keys, and integrity records in Subresource Integrity (<script integrity="sha384-...">) all use hashes so the same input always produces the same identifier.

Hash Algorithm Comparison

Property	MD5	SHA-1	SHA-256	SHA-512	SHA-3 (Keccak)	BLAKE3
Digest length	128 bit / 32 hex	160 bit / 40 hex	256 bit / 64 hex	512 bit / 128 hex	224-512 bit	256 bit default (XOF: any length)
Year published	1992 (RFC 1321)	1995 (FIPS 180-1)	2001 (FIPS 180-2)	2001 (FIPS 180-2)	2015 (FIPS 202)	January 2020
Standard / spec	RFC 1321	FIPS 180-4 (deprecated)	FIPS 180-4	FIPS 180-4	FIPS 202	IETF draft, not NIST
Collision status	Broken — practical collision Wang et al., 2004	Broken — SHAttered, Google + CWI, Feb 2017	No practical collision	No practical collision	No practical collision	No practical collision
Speed (relative)	Very fast (legacy)	Very fast	Fast (hw-accelerated on most CPUs)	Often faster than SHA-256 on 64-bit CPUs	Slower in software than SHA-2	Fastest — parallel Merkle tree, ~5-10x SHA-256 on multi-core
NIST approved	No	Phasing out by Dec 31, 2030	Yes	Yes	Yes	No (not in FIPS)
Typical use today	Non-security checksums, cache keys	Legacy systems, Git object IDs	Default for TLS, signatures, blockchain, file checksums	Long-term archival signatures, 64-bit servers	Alternative to SHA-2 where Keccak is required	High-throughput pipelines, content-addressed storage, video encoders

Picking the Right Hash for the Job

Use case	Recommended algorithm	Why
Verify a downloaded ISO / installer	SHA-256	Industry default; publishers ship a `.sha256` file beside the download
Maximum throughput on large files	BLAKE3	Parallel tree structure saturates modern multi-core CPUs
TLS / X.509 certificates, code signing	SHA-256 or SHA-384	Required by current CA/Browser Forum baseline requirements
Git object IDs (legacy repos)	SHA-1	Compatibility only; new tooling supports SHA-256
Non-security file dedup, cache keys	MD5 is fine	Collisions don't matter when there's no adversary
Password storage	NEVER MD5/SHA-1/SHA-2/SHA-3 — use Argon2id, scrypt, or bcrypt	Plain hashes are too fast; GPU brute-force is trivial. Use a memory-hard KDF with a per-user salt.
Message authentication	HMAC-SHA-256 (not a bare hash)	Bare hashes are vulnerable to length-extension on SHA-1/SHA-2

Frequently Asked Questions

Which hash should I use for password storage?

None of the algorithms on this page. MD5, SHA-1, and the SHA-2/SHA-3 families are all designed to be fast — a modern GPU can compute billions of SHA-256 hashes per second, which makes them trivially crackable against any leaked database. For passwords, use a memory-hard password-hashing function: Argon2id (OWASP 2024 preferred profile: m=46 MiB (46080), t=1, p=1; minimum: m=19 MiB (19456), t=2, p=1), scrypt, or bcrypt with a work factor of 10 or higher. Each password also needs a unique random salt. Generate strong inputs with our password generator.

Which hash should I use for file integrity?

SHA-256 is the standard choice and what almost every Linux distro, GitHub release, and Docker registry publishes. It's hardware-accelerated on most x86-64 and ARM64 CPUs via SHA-NI / ARMv8 cryptographic extensions. If you control both ends of the pipeline and care about raw throughput on large files, BLAKE3 is roughly 5-10x faster on multi-core CPUs because its internal Merkle-tree structure parallelizes naturally — but it isn't FIPS-approved, so it's a poor fit for regulated environments.

Is MD5 still useful for anything?

Yes, but only outside security. MD5 is fine for cache keys, deterministic IDs, ETag-style change detection, and file deduplication where no attacker is trying to forge a collision. The 2004 attack by Wang et al. and subsequent chosen-prefix work mean MD5 should never be used for digital signatures, TLS certificates, password storage, malware detection, or anywhere an adversary could craft two inputs with the same hash. Treat it like CRC32 with a longer output — a fingerprint, not a security primitive.

What is a collision attack?

A collision is two different inputs that produce the same hash. Because hashes map an infinite input space to a fixed output, collisions must mathematically exist; the question is whether anyone can find them efficiently. Wang et al. demonstrated practical MD5 collisions in 2004 (within an hour on a cluster of the day; now seconds on a laptop). Google and CWI Amsterdam announced the first SHA-1 collision in February 2017 (the SHAttered attack), publishing two PDFs with identical SHA-1 digests after about 6,500 CPU-years of computation. SHA-256, SHA-512, SHA-3, and BLAKE3 have no known practical collisions.

Where are SHA-2 and SHA-3 actually specified?

SHA-2 (which includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256) is defined in FIPS PUB 180-4, published by NIST. SHA-3, based on the Keccak sponge construction, is defined in FIPS PUB 202 and includes SHA3-224, SHA3-256, SHA3-384, SHA3-512, plus the SHAKE128 and SHAKE256 extendable-output functions. Both are free, open standards. NIST formally announced the SHA-1 retirement plan in December 2022, with all federal use to be phased out by December 31, 2030, when FIPS 180-5 is expected to remove SHA-1 entirely.

Why do password hashes need a salt?

A salt is a random per-user value mixed into the password before hashing. Without one, two users with the same password produce identical hashes, which leaks information and lets attackers precompute giant rainbow tables that crack millions of accounts at once. With a unique salt (typically 16 bytes from a CSPRNG), the same password yields a different hash for every user, and an attacker has to brute-force each account individually. The salt is stored alongside the hash — it doesn't need to be secret, only unpredictable and unique.

How much faster is BLAKE3 than SHA-256?

It depends heavily on the input size and the hardware. On a single core, BLAKE3 is comparable to or slightly faster than SHA-256 with SHA-NI hardware acceleration. On long inputs (megabytes and up) with multiple cores or wide SIMD lanes (AVX-512), BLAKE3 scales nearly linearly because its internal binary Merkle tree parallelizes — the BLAKE3 team reports roughly 0.49 cycles per byte on Cascade Lake-SP with AVX-512, several times faster than SHA-256 on the same hardware. For short inputs (under a few kilobytes), the difference is small; the wins come on large files and high-throughput streaming.

Is hashing the same as encryption?

No. Hashing is one-way and produces a fixed-length digest — there is no key, and you cannot recover the input from the hash. Encryption is two-way: a key transforms plaintext into ciphertext, and the same key (symmetric) or matching key (asymmetric) recovers the plaintext. Hashes prove integrity ("this file hasn't changed"); encryption provides confidentiality ("only the recipient can read this"). The two are often combined — for example, a signed JWT contains an encoded payload plus a SHA-256-based signature; you can inspect the payload with our JWT decoder. For converting digests between bases (hex to binary or decimal), use the number base converter.

Does this tool send my input to a server?

No. All hashing runs in your browser via the Web Crypto API (crypto.subtle.digest) and pure-JavaScript implementations for algorithms the browser doesn't natively expose. Your text, file contents, and resulting digests never leave your machine — useful when hashing secrets, internal documents, or anything you wouldn't want logged on a remote server.