Hash Generator

About Hash Generator

How Does a Hash Function Work?

A hash function is a deterministic one-way map from arbitrary input bytes to a fixed-length digest. The same input always produces the same output, but changing a single bit of input flips roughly half the output bits (the avalanche effect). You cannot reverse a digest to recover the original input.

Worked example: hashing the three-character string cat with SHA-256 produces 77af778b51abd4a3c51c5ddd97204a9c3ae614ebccb75a606c3b6865aed6744e. Change one letter to bat and the digest becomes a3c7a58e0a224b3cf45d52f9f9b8e2ddb08d8efac51dbd6bb1eb41c1c3d14ed9 - completely different, but still exactly 64 hex characters. Change it to cat with a trailing space and the digest changes again. That is the avalanche effect in action.

Property	What It Means	Why It Matters
Deterministic	Same input always produces the same hash	Enables verification - hash the file again and compare
Fixed-length output	Regardless of input size, the hash is always the same length	Predictable storage, easy comparison
Avalanche effect	Changing one bit of input changes ~50% of the output bits	Prevents guessing the input from the hash
One-way (pre-image resistant)	Cannot reverse the hash to recover the original input	Protects passwords and sensitive data
Collision resistant	Hard to find two different inputs producing the same hash	Enables use as unique identifiers

Supported Algorithms

Algorithm	Output Length	Hex Characters	Security Status	Common Use
MD5 (RFC 1321)	128 bits	32	Broken - chosen-prefix collisions since 2007	Legacy checksums, non-security file verification
SHA-1 (FIPS 180-4)	160 bits	40	Broken - first public collision Feb 2017	Git object hashes (legacy), old certificate chains
SHA-256 (FIPS 180-4)	256 bits	64	Secure - NIST-approved	TLS, code signing, blockchain, content-addressing
SHA-512 (FIPS 180-4)	512 bits	128	Secure - NIST-approved	High-security applications, 64-bit performance

The SHA-2 family (SHA-256 and SHA-512) was published by NIST in FIPS 180-2 in 2002 and remains the default recommendation for new systems. SHA-3 (FIPS 202, 2015) is based on the Keccak sponge construction and is available alongside SHA-2, not as a replacement.

How Have MD5 and SHA-1 Been Broken?

Both algorithms are considered cryptographically broken because researchers can produce two different inputs that hash to the same digest in a feasible amount of computing time.

MD5. Xiaoyun Wang and Hongbo Yu demonstrated the first public MD5 collision at the CRYPTO 2004 rump session. By 2007 Marc Stevens, Arjen Lenstra, and Benne de Weger had produced chosen-prefix collisions with around 2^50 MD5 compressions, later reduced to roughly 2^39 in 2009 - about a day on a commodity quad-core. In 2008 a research team used the technique to forge a rogue X.509 certificate signed by a real commercial CA, demonstrating that MD5 was unsafe for any signature context.

SHA-1. On 23 February 2017 Google and CWI Amsterdam published SHAttered, the first public SHA-1 collision: two PDF files with identical SHA-1 hashes but different content. The attack used roughly 2^63.1 SHA-1 compressions - about 6,500 CPU years and 110 GPU years, bought on cloud hardware for around $110,000. In 2019 Gaetan Leurent and Thomas Peyrin published a chosen-prefix SHA-1 collision (SHA-1 is a Shambles) for roughly $45,000, putting signature forgery in reach of resourced attackers. Shortly after, NIST formally deprecated SHA-1 in SP 800-131A and announced a full retirement date of 31 December 2030.

Which Hash Should You Use?

Purpose	Use	Do Not Use
Password hashing	bcrypt, scrypt, or Argon2id (OWASP 2026)	MD5, SHA-1, or unsalted SHA-256
Digital signatures and code signing	SHA-256 or SHA-512	MD5, SHA-1
TLS certificates	SHA-256 (minimum, per CA/Browser Forum Baseline Requirements)	SHA-1 (disallowed in public certs since 2017)
File integrity checksums (non-adversarial)	SHA-256 - MD5 still common on mirrors but no longer recommended	N/A
HMAC authentication	HMAC-SHA-256 or HMAC-SHA-512	HMAC-MD5 for new designs
Fast cache keys, deduplication	SHA-256, or MD5/xxHash if collisions are acceptable	N/A

Raw SHA-256 is not suitable for password storage because it is fast - a modern GPU can compute billions of SHA-256 hashes per second, which makes brute-force and dictionary attacks cheap. Use a deliberately slow password hash such as bcrypt (our Bcrypt Generator) or Argon2id. For keyed message authentication use the HMAC Generator, which combines a secret with a hash function in the construction defined by RFC 2104.

How Do Real Systems Use Hashes?

System	Hash	Notes
Git (default repositories)	SHA-1	Still SHA-1 by default in Git 2.51 (Aug 2025); SHA-256 object format graduated from experimental in Git 2.42 (2023); interop and tooling work is ongoing toward Git 3.0.
Bitcoin	Double SHA-256	Block headers are hashed as SHA-256(SHA-256(header)); addresses use RIPEMD-160 over SHA-256.
Ethereum	Keccak-256	Pre-standardised variant of SHA-3, used for contract addresses, transaction hashes, and Merkle tries.
TLS 1.3 certificates	SHA-256 / SHA-384	CA/Browser Forum disallows SHA-1 in publicly trusted certificates.
Linux package managers	SHA-256 / SHA-512	Debian, Fedora, Arch all publish SHA-256 (and often SHA-512) digests in repository metadata.
AWS S3 / object storage ETags	MD5 (single-part) / custom (multipart)	MD5 is used only as an integrity check against accidental corruption, not as a security primitive.
HMAC in JWT (HS256)	HMAC-SHA-256	Shared-secret signing of JSON Web Tokens; see the JWT Decoder.

How Long Is a Brute-Force Pre-Image Attack?

For a secure n-bit hash, finding a pre-image (an input that hashes to a target digest) requires on average 2^(n-1) hash computations, and finding any collision requires about 2^(n/2) by the birthday bound. The table below shows the search space in practical terms and why a 128-bit security level is the modern floor for new systems.

Hash size	Pre-image work	Birthday collision work	Practical status
MD5 (128-bit)	2^127	2^64	Collisions broken in practice; pre-image still 2^123.4 in best published attack
SHA-1 (160-bit)	2^159	2^80 (theory) / 2^63.1 (SHAttered)	Collisions broken; forgery demonstrated
SHA-256 (256-bit)	2^255	2^128	No known weaknesses; considered secure for decades
SHA-512 (512-bit)	2^511	2^256	No known weaknesses; slightly faster than SHA-256 on 64-bit CPUs

The birthday numbers matter because collision resistance - not pre-image resistance - is what protects signatures and Git commit identifiers. That is why MD5 and SHA-1 are unsafe for signing even though pre-image attacks on them are still infeasible.

Hash Output Formats and Encodings

This tool prints digests in hexadecimal - each byte becomes two characters from 0-9a-f. Hex is the convention used by Git, npm integrity fields (after decoding from base64), sha256sum, and most checksum files. Toggle to uppercase if a legacy tool or mainframe system expects it. Other common encodings you may encounter include Base64 (shorter, used in Subresource Integrity headers - sha256-... values are base64-encoded) and binary (used internally by protocols). If you need to encode rather than hash, use the Base64 Encoder/Decoder.

How Is the Input Bytes Processed Before Hashing?

This tool treats the text box as a UTF-8 byte sequence before hashing. A single emoji like the grinning face U+1F600 encodes to four bytes (F0 9F 98 80), so its SHA-256 is the digest of those four bytes, not of a 16-bit JavaScript code unit. That matches how almost every modern system hashes text: sha256sum on Linux, Node's crypto.createHash, Python's hashlib, and Git's internal hash-object all hash raw bytes, and default to UTF-8 when given strings.

Why the encoding choice matters: hashing the same visible characters under different encodings produces different digests. The string naïve in UTF-8 (7 bytes) and in Latin-1 (5 bytes) are different byte sequences and therefore have different SHA-256 values. If you need to compare a hash computed by another tool, check that the other tool also uses UTF-8 and does not add or strip a byte order mark or trailing newline. The classic gotcha is running echo "hello" | sha256sum on Linux, which hashes hello\n (six bytes) - not the five bytes you probably meant. Use printf '%s' "hello" | sha256sum for byte-exact input.

For binary files you rarely need a browser tool - sha256sum filename, PowerShell's Get-FileHash, or macOS shasum -a 256 filename will hash the raw file bytes directly with no encoding guesswork.

Common Mistakes with Hashes

Treating a hash as if it were encryption is the most common mistake. Hashes are one-way - there is no key and no decryption function. Storing a password as sha256(password) is only marginally better than storing it in plain text because precomputed "rainbow" tables cover most common passwords in seconds. Another recurring mistake is comparing hashes with a non-constant-time equality operator in security code, which can leak information through timing side channels - use a library like Node's crypto.timingSafeEqual or Python's hmac.compare_digest. A third is assuming that two files with identical MD5s are the same file: since 2008 any adversary can construct MD5 collisions cheaply, so MD5 is only valid as an accidental-corruption check. Finally, remember that hashing the same text twice in different tools can produce different results if one tool is silently normalising line endings, trimming whitespace, or adding a newline - always compare byte-for-byte.

Sources

• RFC 1321 - The MD5 Message-Digest Algorithm (Rivest, IETF)
• NIST FIPS 180-4 - Secure Hash Standard (SHA-1, SHA-256, SHA-512)
• NIST CSRC - Research Results on SHA-1 Collisions (2017)
• SHAttered - First SHA-1 Collision (Google / CWI, Feb 2017)
• Stevens, Lenstra, de Weger - Chosen-Prefix Collisions for MD5 and Applications
• RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
• OWASP - Password Storage Cheat Sheet
• Git - Hash Function Transition (SHA-1 to SHA-256)