Hash Generator

Input Section

Input text

Output Section

MD5

3500c827000bded5b76acb2edfb42fb2

SHA-1

c6506e8042334d9ac0aac210772160893d954f15

SHA-256

2b3d73ec5437a40214ae9a9ce44194353278c695edf7d33a39eb77da6499c48c

SHA-512

06f411707036a632af4ebba87984a3e888f0661463eae9d1197f912200ee01cd7dbbb6df33b6e519d700493d8065bb9e5ece5a4a3b2b9d0bd30a171ed514e38f

What is a cryptographic hash function?

A cryptographic hash function is a deterministic algorithm that takes an input of arbitrary length — a single character, a 10 GB file, or anything in between — and produces a fixed-length output called a digest or hash. Three properties define a cryptographic hash function:

Deterministic: The same input always produces the same output. Hash("DevToolsHub") will always return the same 64-character string on every computer, every time.
Avalanche effect: Changing a single bit anywhere in the input completely changes the output — roughly half the output bits flip. This makes it impossible to predict how the hash will change from a small input modification.
One-way (pre-image resistance): Given a hash output, it is computationally infeasible to reverse-engineer the original input. There is no decryption step.

A secure hash function also provides collision resistance — it should be computationally infeasible to find two different inputs that produce the same output hash. Collision resistance is the property that MD5 and SHA-1 have lost.

Algorithm comparison table

Algorithm	Standard	Output bits	Hex string length	Security status	Typical use
MD5	RFC 1321 (1992)	128 bits	32 characters	Broken — collision attacks practical (2004)	Non-security checksums, cache keys, ETags, deduplication identifiers
SHA-1	FIPS 180-1 (1995)	160 bits	40 characters	Broken — SHAttered collision (2017)	Git object addressing (legacy), TLS/code-signing revoked, not for new systems
SHA-256	FIPS 180-4 (2015)	256 bits	64 characters	Secure	TLS certificates, code signing, blockchain (Bitcoin), JWT HS256, Docker image digests, HMAC-SHA256
SHA-512	FIPS 180-4 (2015)	512 bits	128 characters	Secure	High-security archival hashing, password KDFs (PBKDF2 inner hash), systems requiring >256-bit output

How SHA-256 works — the Merkle-Damgård construction

SHA-256 is built on the Merkle-Damgård construction, defined in FIPS PUB 180-4 (Secure Hash Standard). Understanding the internals explains why the algorithm has the properties it does and why changing one byte produces a completely different output.

Pre-processing (padding): The input message is padded to a length that is a multiple of 512 bits. Padding appends a single 1 bit, then enough 0 bits, then a 64-bit big-endian encoding of the original message length. This ensures every input maps to a unique padded representation.
Block splitting: The padded message is split into 512-bit (64-byte) blocks. Each block is processed sequentially through the compression function.
Message schedule: Each 512-bit block is expanded from 16 32-bit words into a 64-word message schedule using bit rotation and XOR operations. This expansion means every bit of the original block influences 64 rounds of mixing.
64 compression rounds: SHA-256 maintains 8 working variables (a–h), each 32 bits wide, initialised to the fractional parts of the square roots of the first 8 prime numbers. In each round, the working variables are mixed using bitwise operations (AND, OR, XOR), modular addition, and bit rotation by constants derived from the cube roots of the first 64 primes. The output of one round feeds directly into the next.
State update: After all 64 rounds, the round output is added (modulo 2³²) to the previous hash state. This addition is the source of the chaining — the full history of every prior block is folded into the current state.
Final hash: After the last block, the 8 working variables are concatenated to produce the 256-bit (32-byte) hash, typically displayed as a 64-character hexadecimal string.

The reason a one-bit change to the input produces a completely different hash is that the changed bit propagates through the message schedule expansion and then through 64 rounds of nonlinear mixing — each round amplifying the change until essentially every output bit is affected. This is the avalanche effect.

HMAC — Hash-based Message Authentication Code

A plain hash (SHA-256) only tells you whether data has changed — it does not tell you who produced it. Any attacker who knows your data can recompute the SHA-256 hash and produce a valid-looking value. HMAC (defined in RFC 2104) combines the hash function with a secret key to produce a value that only someone who knows the key can reproduce.

HMAC-SHA256 is computed as:

HMAC(key, message) = SHA256((key ⊕ opad) ∥ SHA256((key ⊕ ipad) ∥ message))

where opad is the outer padding (0x5c repeated) and ipad is the inner padding (0x36 repeated). The double-hash construction prevents length-extension attacks that affect plain SHA-256 when a secret prefix is naively prepended.

HMAC-SHA256 is used in: JWT tokens with algorithm HS256, AWS Signature Version 4 request signing, Webhook payload verification (GitHub, Stripe, Twilio), and TOTP/HOTP one-time password generation.

Why you must never hash passwords directly with SHA-256

SHA-256 is intentionally fast — a modern GPU (NVIDIA RTX 4090) can compute approximately 22 billion SHA-256 hashes per second. This speed is desirable for file integrity checking but catastrophic for password storage. An attacker with a leaked database of SHA-256-hashed passwords can test every common password and dictionary word in seconds.

For password storage, use a dedicated slow hashing function:

bcrypt: Industry standard. Work factor of 12+ takes ~250ms per hash, making bulk cracking impractical. Used by default in most authentication frameworks (Devise, Passport.js, ASP.NET Core Identity).
Argon2id: Winner of the Password Hashing Competition (2015). Configurable memory and CPU cost. The current recommended choice for new systems. Resistant to GPU and ASIC acceleration due to its memory-hard design.
PBKDF2-SHA256: Approved by NIST (SP 800-132). Uses SHA-256 internally but iterates it 600,000+ times (NIST 2023 recommendation). Required for FIPS compliance environments.

All three algorithms include a built-in random salt — a random value unique to each user generated at password creation time. The salt ensures that two users with the same password produce different stored hashes, defeating rainbow table attacks entirely.

Hash salting and rainbow table resistance

A rainbow table is a precomputed lookup table mapping common passwords to their hashes. Without salting, an attacker with a leaked hash database can find any password that appears in the table with a single lookup. Salting defeats this by making every hash unique even for identical passwords: the input to the hash function is concat(salt, password), and the attacker would need a separate table for every possible salt value — a storage and compute requirement that makes precomputation infeasible.

The salt does not need to be secret — it is typically stored in the same database row as the hash. Its only purpose is uniqueness. An effective salt is at least 16 bytes of cryptographically random data generated with a secure random number generator (crypto.randomBytes in Node.js, secrets.token_bytes in Python, crypto/rand in Go).

Real-world production use cases

Docker content addressing: Every Docker image layer is identified by its SHA-256 digest. The image reference ubuntu@sha256:abc123... pins the exact bytes — if the registry returns different content, the hash won't match and the pull fails. This is how Docker ensures image integrity without trusting the registry.
Git object storage: Git identifies every commit, tree, and file blob by its SHA-1 hash (being migrated to SHA-256 in git 2.x). The hash is the address — two repositories with the same SHA-1 for a commit are guaranteed to have identical content for that commit.
TLS certificate fingerprints: When pinning a TLS certificate in a mobile app or API client, the SHA-256 fingerprint of the certificate's DER-encoded bytes is stored. The client verifies the server's certificate fingerprint matches before proceeding — a mismatch indicates a potential MITM attack.
File integrity verification: Software releases publish SHA-256 checksums alongside download files. After downloading, compute the file's SHA-256 and compare it to the published value. A match guarantees the file was not corrupted in transit or tampered with by the distribution server.
JWK thumbprints (RFC 7638): JSON Web Key thumbprints use SHA-256 to produce a stable identifier for a public key, independent of how the key is serialised. Used in OAuth 2.0 DPoP and JOSE specifications.
Deduplication: Object storage systems (S3, GCS, Cloudflare R2) use MD5 or SHA-256 of content to detect duplicate uploads. Storing the hash as a key means identical files share a single storage location without byte-for-byte comparison.

Data processing — where your input goes

When you click Hash, your input text is sent over HTTPS to the DevToolsHub API (hosted on Microsoft Azure). The API computes all four hashes using .NET's System.Security.Cryptography library and returns the results immediately. The API does not log request payloads — only operational metadata (response status code, latency) is retained for 24 hours. See the Privacy Policy for full details.

Native code equivalents

Production-ready snippets — same logic the tool runs, in your language

All processing is client-side · zero data retention

// Node.js built-in crypto — no npm package required
const crypto = require('crypto');

// SHA-256 (recommended default for security-sensitive use)
const sha256 = (text) => crypto.createHash('sha256').update(text, 'utf8').digest('hex');

// SHA-512
const sha512 = (text) => crypto.createHash('sha512').update(text, 'utf8').digest('hex');

// MD5 (non-security use only — checksums, cache keys, ETags)
const md5 = (text) => crypto.createHash('md5').update(text, 'utf8').digest('hex');

// HMAC-SHA256 — used for JWT signing (HS256) and API authentication
const hmacSha256 = (text, secret) =>
  crypto.createHmac('sha256', secret).update(text, 'utf8').digest('hex');

console.log(sha256('DevToolsHub'));
// 3e71e0b23d4b6b2f3e3f6f8e0d3e7e5a...

// Hash a file (Node.js streams)
const fs = require('fs');
const hash = crypto.createHash('sha256');
fs.createReadStream('file.txt').pipe(hash).on('finish', () => {
  console.log('File SHA-256:', hash.digest('hex'));
});

FAQ

Which algorithm should I use?

SHA-256 for all security-sensitive work: file integrity, TLS fingerprinting, API signing, JWT HS256. MD5 is acceptable for non-security purposes such as cache keys and ETags. Avoid SHA-1 for any new system.

Is my input sent to a server?

Yes — text is sent to the DevToolsHub API over HTTPS where the hash is computed by System.Security.Cryptography and returned. The input is not logged or stored. See the Privacy Policy for details.

What is the difference between MD5 and SHA-256?

MD5 produces a 128-bit hash (32 hex chars) and is cryptographically broken — collision attacks are practical. SHA-256 produces a 256-bit hash (64 hex chars) and is secure for all current threat models.

Can I reverse a hash?

No. Hashing is a one-way function with no decryption. Common short values can be found via rainbow tables (pre-computed lookup tables), which is why salting is essential for password storage.

What is HMAC-SHA256 and when should I use it?

HMAC-SHA256 combines SHA-256 with a secret key to produce a message authentication code. Use it when you need to verify both data integrity and the identity of the sender — JWT HS256 tokens, webhook verification, and API request signing all use HMAC-SHA256.

Why can't I use SHA-256 for passwords?

SHA-256 computes ~22 billion hashes per second on a modern GPU. An attacker with your hashed password database can crack common passwords in seconds. Use bcrypt, Argon2id, or PBKDF2 — all are intentionally slow and include a built-in salt.

When should I use SHA-512 over SHA-256?

SHA-512 is faster on 64-bit CPUs (wider internal registers) and provides 512 bits of output. Use it when you need a larger security margin, when the downstream system requires 512-bit hashes, or as the inner hash in PBKDF2 for password hashing.

What is the difference between a hash and a checksum?

In practice the terms are often interchangeable. Technically, a checksum (like CRC32) is designed for error detection (not security), while a cryptographic hash (SHA-256) is designed for both error detection and security. Use SHA-256 for any use case where tampering detection matters.