11 Hashing Types: Cryptographic, Password, and Fast Hash Functions

Change Textavia to textavia and the hashing types built for integrity produce entirely different digests, even though only one letter changed case.

The choice comes down to the job. Use SHA-256 or another current cryptographic hash for integrity and digital-signature systems, Argon2id or another password hashing function for login credentials, and a non-cryptographic hash such as xxHash for fast lookup or partitioning where hostile collisions are outside the threat model.

For immediate inspection, the SHA hash generator produces SHA-1, SHA-256, SHA-384, and SHA-512 from text. The MD5 generator is useful for reproducing a legacy checksum. Both run in the browser; password storage requires a dedicated library.

Hashing types at a glance

Those labels matter. Argon2id is often called a hash, but its useful property is configurable cost. xxHash creates a hash value too, yet it makes no promise that finding a collision will be hard. A single ranking from “weak” to “strong” cannot describe all three classes.

Three families before the list

Cryptographic hash functions turn any amount of data into a digest. Traditional functions return a fixed size; extendable-output functions return the length requested by the calling protocol. A security-grade function resists recovery of an input from its digest. It also makes second-preimage and deliberate collision attacks impractical. NIST currently standardizes SHA-2 in FIPS 180-4 and SHA-3 in FIPS 202.

Password hashing functions and password-based KDFs add salt plus adjustable time, memory, or both. Slowness is intentional. One login should remain tolerable while millions of guesses become expensive.

Non-cryptographic hash functions chase throughput and useful distribution. They work well inside hash tables, caches, partitioners, and data-processing pipelines. Their speed is exactly why they cannot stand in for a cryptographic digest.

1. MD5 for legacy compatibility

MD5 accepts arbitrary-length input and returns 128 bits, usually displayed as 32 hexadecimal characters. It is deterministic and quick. Its collision resistance is broken.

That last sentence controls the decision. RFC 6151 says MD5 is unacceptable where collision resistance is required. The RFC leaves room for an inline checksum used only to catch accidental transmission errors, provided the application does not claim a security service from it.

Use MD5 when a legacy API, archive, or vendor publishes an MD5 value and you need to compare like with like. If someone could replace both the file and its published digest, matching values prove very little. Prefer a signed release and a current digest for software distribution.

The MD5 generator hashes text strings. A file checksum command hashes the file's bytes, so pasting a filename or a text preview into the browser tool will not reproduce a file digest.

2. SHA-1 for old systems you cannot change yet

SHA-1 produces a 160-bit digest. It survived longer than MD5, but practical collision research ended its place in new security work. NIST has set a transition away from SHA-1 and recommends moving to SHA-2 or SHA-3.

You may still encounter SHA-1 in old object IDs, certificates, and protocol fields. Treat that as migration work. Do not design a new signature, certificate, or integrity format around it.

Compatibility can be a valid requirement. Quietly calling compatibility “secure” is where the trouble begins.

3. SHA-2 for current, widely supported integrity work

SHA-2 names a family of algorithms. SHA-256 returns 256 bits, while SHA-512 returns 512. SHA-224, SHA-384, SHA-512/224, and SHA-512/256 round out the family described in FIPS 180-4.

SHA-256 is the ordinary default for file digests and interoperable security protocols. SHA-512 may perform well on 64-bit processors and gives a longer digest, though more output bits do not repair a weak surrounding design.

Use SHA-2 for:

• Comparing a file against a SHA-256 value obtained through a trusted channel.
• A digest inside a vetted digital-signature scheme. The signature construction still matters.
• HMAC-SHA-256 when the sender and verifier share a secret key.
• Content-addressed storage where collision resistance is part of the design.

A plain SHA-256 digest does not authenticate its input. Anyone who can edit a message can calculate a fresh digest. Add a keyed construction such as HMAC when you need proof tied to a secret.

4. SHA-3 when the protocol calls for it

SHA-3 offers SHA3-224, SHA3-256, SHA3-384, and SHA3-512. It uses a sponge construction rather than the construction behind SHA-2, giving system designers a standardized alternative with a different internal design.

SHA-3 also includes the extendable-output functions SHAKE128 and SHAKE256. Their output length is chosen by the calling protocol. That flexibility is useful, but it makes “SHA-3 output length” an incomplete specification. Record the exact function and output size.

Choose SHA-3 when a standard or interoperability target asks for it, or when design diversity from SHA-2 has a concrete benefit. SHA-256 remains a sound default in systems already built around it.

5. BLAKE2 for fast cryptographic hashing

BLAKE2b is tuned for 64-bit platforms, while BLAKE2s targets smaller architectures. The family can generate variable-length digests and has a native keyed mode. Its specification is published as RFC 7693.

It is a strong fit for content addressing, deduplication with an adversarial threat model, and applications that control both ends of the format. Check ecosystem support before choosing it for a public protocol. SHA-256 is easier to find in hardware, command-line tools, compliance documents, and third-party APIs.

BLAKE3 is a newer, parallel design descended from BLAKE2. It has attractive performance, but it is a distinct algorithm with a distinct output format. Do not shorten “BLAKE2 or BLAKE3” to “BLAKE” in a specification.

6. Argon2id for new password storage

Argon2id spends both memory and CPU time on each guess. That makes specialized cracking hardware pay more than it would against MD5, SHA-1, or plain SHA-256. The id variant combines properties of Argon2i and Argon2d.

OWASP's current Password Storage Cheat Sheet recommends Argon2id first and publishes baseline memory, iteration, and parallelism settings. RFC 9106 defines the algorithm and profiles.

Store the algorithm identifier, salt, cost parameters, and derived value together in the library's standard encoded format. Then tune the cost on your own production-class hardware. A setting that stalls every login for several seconds creates a denial-of-service problem; one that finishes almost instantly ages badly.

Do not build this format by joining fields yourself. Use a maintained password library that verifies and upgrades encoded hashes.

7. scrypt when memory hardness and compatibility meet

scrypt is a password-based KDF designed to require significant memory as well as computation. RFC 7914 specifies it for broad implementation.

It remains a reasonable choice when Argon2id is unavailable in the approved stack. The parameters N, r, and p interact, and memory usage can surprise a server under concurrent login load. Use framework defaults as a starting point, load-test them, then document the exact settings.

A random salt is required and can be stored beside the result. Its purpose is to make equal passwords derive different records and defeat precomputed tables.

8. bcrypt for established password databases

bcrypt has protected passwords for decades and supports an adjustable work factor. Its broad library support makes it common in mature applications.

There is a sharp edge. Many bcrypt implementations use only the first 72 bytes of a password. Bytes and visible characters are different once UTF-8 enters the room. OWASP now positions bcrypt mainly for legacy systems and calls out that input limit in its password-storage guidance.

Keep bcrypt when the existing system is well maintained and migration risk is real. Rehash a successfully verified password into Argon2id over time if the platform supports it. For a new service, start with Argon2id instead of creating another bcrypt migration later.

9. PBKDF2 for regulated or highly compatible environments

PBKDF2 repeatedly applies a pseudorandom function, commonly HMAC-SHA-256, with a salt and iteration count. It is standardized in RFC 8018 and is widely available in platform cryptography APIs.

Its strength is compatibility. Its drawback is that the design raises CPU cost without the memory hardness of Argon2id or scrypt. Pick an iteration count from current guidance, benchmark it on the real authentication tier, and plan to raise it.

“PBKDF2” alone is incomplete configuration. Record the PRF, iterations, salt, and derived-key length.

10. xxHash for throughput

xxHash is a family of extremely fast, non-cryptographic functions. XXH32 and XXH64 are common; XXH3 adds 64-bit and 128-bit variants. The xxHash project publishes the reference implementation and compatibility details.

Use it for in-memory hash tables, compression indexes, partition selection, or a quick first pass in a duplicate-detection pipeline. Confirm suspected duplicates byte for byte when a false match has consequences.

Never use xxHash for password storage, signatures, API-token verification, or downloads where an attacker may shape the input. A 128-bit non-cryptographic output does not inherit cryptographic collision resistance just because its width resembles a digest.

11. MurmurHash for distribution in data systems

MurmurHash is another fast, non-cryptographic family. MurmurHash3 appears in hash tables, search systems, Bloom filters, feature hashing, and sharding code because it distributes ordinary inputs well and has implementations across languages.

Version and seed are part of the contract. MurmurHash3 x86 32-bit, x86 128-bit, and x64 128-bit variants do not promise interchangeable output.

Do not treat the seed as a cryptographic key. If untrusted users can choose inputs and collisions could overload one bucket, choose a design intended to resist hash-flooding attacks, such as a keyed hash-table function supplied by the runtime.

Hashing vs encryption

Hashing and encryption answer different questions.

If the application must display a stored credit-card number later, it needs encryption and controlled key access. If it only needs to check whether a login attempt matches the enrolled password, use a password hashing function. Base64 belongs to neither group; it is reversible encoding for representation.

MD5 vs SHA-2 in one local test

I tested three inputs with the same UTF-8 bytes used by Textavia's text hash tools. Case and the final newline changed every digest.

The output length is the visible clue. MD5 is 32 hex characters and SHA-256 is 64 because each hex character represents four bits. The security difference goes deeper. MD5 collision resistance is broken; SHA-256 remains an approved cryptographic hash.

Try the same input in the MD5 generator and SHA hash generator. Include every space and newline when comparing results.

How to choose a hash function

Start with what failure would cost.

• A malicious file substitution calls for a current cryptographic digest delivered through a trusted or signed channel.
• Password database breach in scope. Use Argon2id with a unique salt and measured cost settings, through a maintained library.
• An internal cache key with no security consequence may favor xxHash for speed.
• Protocol compatibility. Implement the exact named algorithm, version, parameters, byte encoding, and output encoding.
• A digital signature needs the signature standard's approved digest. Do not swap one in because its hexadecimal string looks similar.

Also define the input. Hash raw bytes or a precisely specified encoding. Unicode normalization, line endings, JSON key order, and invisible trailing whitespace can all change a digest while the screen appears almost unchanged.

Answers that catch bad designs early

Different inputs can have the same hash. A fixed-size output has fewer possible values than arbitrary-length input, so collisions must exist. Cryptographic collision resistance makes finding a useful one infeasible; it never makes collisions mathematically impossible.

A hash has no decryption function. Weak or common inputs can still be guessed, hashed, and compared. That is why unsalted fast password hashes fail so quickly.

SHA-256 alone is insufficient for passwords. SHA-256 is designed to be fast. Password storage needs salt plus deliberately expensive verification, usually Argon2id.

A matching file hash has a narrow meaning. It shows that the bytes match the bytes behind the expected digest, assuming the hash remains collision-resistant for that use. The result says nothing about the publisher's trustworthiness, the software's behavior, or the channel that delivered the expected digest.

MD5 has a limited deduplication role. Use it only when accidental duplicates are the whole problem and a byte-for-byte confirmation handles matches. Choose a current cryptographic hash if users can submit crafted files or if a false match could discard data.

The main types of hash functions serve separate jobs. For practical software decisions, separate cryptographic hashes from password hashing functions or KDFs. Non-cryptographic hashes form the third group. Checksums such as CRC32 sit nearby, though they are built to detect accidental errors.

The algorithm name is only the beginning. Write down the exact variant, input bytes, output encoding, parameters, and threat model before a hash becomes part of a durable format.