Hash Generator Reference

What Is SHA-256?

Because SHA-256 underlies TLS certificates, software package verification, and blockchain consensus, understanding what it produces is essential for anyone working with security infrastructure¹. SHA-256 is a member of the SHA-2 family, published by NIST in 2001 under FIPS 180-4², and remains the de-facto standard hash function for general security use in 2026.

What is SHA-256?

Internal structure and output properties

SHA-256 processes input in 512-bit blocks through a series of 64 rounds⁵, each applying bitwise operations, modular addition, and message schedule functions. The algorithm maintains an internal state of eight 32-bit words, initialized to constants derived from the fractional parts of the square roots of the first eight prime numbers. Consequently, the output is deterministic and uniformly distributed across the 2^256 possible values - no input produces a predictably "higher" or "lower" hash. The avalanche effect means a one-bit change in input causes approximately half the output bits to change.

Why fixed length matters

A fixed 256-bit output makes SHA-256 easy to store, compare, and index. Whether the input is a short password candidate or a multi-gigabyte disk image, the digest remains 32 bytes before encoding. That predictable length is why SHA-256 fits cleanly into database columns, API schemas, logs, and content-addressed storage systems. Variable-length outputs would complicate every downstream system that stores or compares hashes, because the consumer would need to know the input size to allocate the right amount of space for the digest.

You benefit from the fixed length whenever you store, compare, or index a digest, because the predictable size fits cleanly into database columns and API schemas. A 32-byte output means every downstream system can allocate the same space whether the input is a password candidate or a disk image. CapyToolkit shows SHA-256 output in your browser so you can confirm the 64-character length before copying the value into a field.

Security status and attack resistance

SHA-256 has no known practical collision, preimage, or second-preimage attacks as of 2026. Finding a collision (two inputs with the same hash) requires approximately 2^128 operations under current theoretical understanding - computationally infeasible with any foreseeable classical computing technology. Quantum computers running Grover's algorithm reduce preimage search to approximately 2^128 operations, which remains infeasible at current and projected quantum hardware capabilities. Yet researchers continue analyzing SHA-256 against future attack methods; NIST developed SHA-3 as a structural backup should weaknesses emerge in SHA-2.

What SHA-256 does not prove

A matching SHA-256 value proves the bytes match the value you compared. It does not prove the source is trustworthy, the software is safe, or the key used to create an HMAC is valid. Pair SHA-256 with trusted checksum sources, authenticated channels, or HMAC when the result affects trust decisions. Think of a hash as a fingerprint for data: it confirms the data has not changed, but it says nothing about whether the data was good or trustworthy in the first place, which is why secure systems combine hashing with signatures and authenticated delivery channels.

Common applications

SHA-256 appears in TLS certificate signatures (every HTTPS connection), Bitcoin and most cryptocurrency proof-of-work systems, software package managers (npm integrity, macOS code signing, apt), and digital signatures under RSA and ECDSA. Building on this breadth: choosing SHA-256 gives maximum compatibility across languages, libraries, and platforms. The algorithm is hardware-accelerated on modern Intel, AMD, and ARM processors via dedicated instructions (Intel SHA-NI, ARMv8 Crypto Extension), making it fast enough for high-throughput applications.

Choosing SHA-256 when interoperability matters

SHA-256 is the least surprising choice when another system must read the same digest. Most languages include it in the standard library, most checksum tools understand it, and most documentation assumes a 64-character lowercase hex string. That ecosystem support reduces integration risk compared with newer algorithms. When you are building a system that other teams or external partners will consume, choosing SHA-256 means they can verify your checksums with whatever tools they already have installed, without needing to install a specialized library or learn a new output format.

SHA-256 compared with SHA-3 and BLAKE3

SHA-3 (Keccak) was standardized by NIST in 2015 as a structural backup to SHA-2, not a direct replacement. SHA-3-256 produces the same 256-bit output as SHA-256 using a completely different internal construction called the sponge function, which shares no design elements with SHA-2's Merkle-Damgard structure. NIST developed SHA-3 to ensure that a structural weakness in SHA-2, if discovered, would not compromise the backup algorithm. Both SHA-256 and SHA-3-256 remain secure as of 2026, with no practical attacks on either.

BLAKE3, released in 2020, outperforms SHA-256 in software on modern CPUs and provides comparable security. It is not yet NIST-approved, which excludes it from FIPS 140-3 validated systems, PCI-DSS, HIPAA, and FedRAMP contexts. For developer tooling, package managers, and internal systems without compliance requirements, BLAKE3 is technically sound. SHA-256 remains the correct default for any application that may require regulatory validation.

On modern CPUs, SHA-256 runs on dedicated hardware instructions

Intel processors with the SHA-NI extension, available since Goldmont microarchitecture (2016), and ARM processors with the ARMv8 Crypto Extension execute SHA-256 on dedicated processing units rather than general-purpose arithmetic pipelines. These instructions accelerate SHA-256 to multi-gigabyte-per-second throughput on a single core, fast enough that memory access rather than computation becomes the throughput bottleneck for most file hashing workloads.

Most language runtimes use these instructions automatically when the hardware supports them. Python's hashlib delegates to OpenSSL, which detects and activates SHA-NI at startup. Node.js inherits the same behavior through its OpenSSL dependency. Java's JVM applies similar optimizations. You do not need to configure anything to benefit from hardware acceleration; the speedup is transparent at the library level.

Try in the tool

What Is MD5?

Although MD5 produces collisions too easily for cryptographic security¹, it remains pervasive in checksum files, legacy databases, and developer tooling because it is fast and universally supported. Knowing what MD5 is - and what it is not - determines when you can use it safely and when it introduces risk.

What is MD5?

Why MD5 is cryptographically broken

A collision attack finds two different inputs that produce the same hash without any knowledge of a target input. MD5 collision attacks have been practical since 2004, when researchers from Xiaoyun Wang's group demonstrated the first full MD5 collision. The Flame malware (2012) exploited an MD5 collision in the Microsoft Terminal Server Licensing service to forge a code-signing certificate⁵, demonstrating that MD5 collisions are not merely academic. Consequently, MD5 cannot protect against an adversary who is motivated to forge the hash. Yet a random cosmic ray flipping a bit in a downloaded file is not an adversary - MD5 catches accidental corruption just as reliably as SHA-256.

Naming the threat model

Before choosing MD5, state whether the file can be chosen by an attacker. If the answer is no, MD5 can be a reasonable checksum for accidental corruption. If the answer is yes, choose SHA-256. The algorithm decision should follow the trust boundary, not the convenience of existing examples. Write the threat model down in a comment or design document near the hash call site, so the next developer understands why MD5 was chosen and knows the conditions under which it must be upgraded to SHA-256.

You make the right call by stating whether the file in question can be chosen by an attacker before you accept MD5 for the job. A trusted internal pipeline can use MD5 to catch accidental corruption, while any externally influenced download needs SHA-256. CapyToolkit computes MD5 locally so you can verify a legacy checksum without uploading the file, but it points you to SHA-256 for anything that affects trust.

MD5 for password storage is never acceptable

MD5 is a fast hash function, designed to process data as quickly as possible. Furthermore, MD5 with no salt means that every user with the same password gets the same hash, enabling lookup table attacks. Databases of precomputed MD5 hashes for billions of common passwords exist publicly. A database of MD5-hashed passwords is effectively a database of plaintext passwords against these lookup tables. Even salted MD5 is unacceptable for modern password storage because the speed that makes MD5 useful for checksums (hundreds of millions of operations per second on a GPU) makes it trivially brute-forceable for passwords. Use bcrypt, scrypt, or Argon2 instead.

Legitimate uses of MD5 in 2026

MD5 remains appropriate for non-security checksums: detecting accidental file corruption in a trusted pipeline, generating cache keys for content-addressed storage, computing database shard keys, and reading checksums published by legacy systems. Building on this pragmatic view: if you are processing a file through an internal pipeline with no adversarial exposure, MD5 provides fast integrity verification. The moment an adversary could influence the file content - external downloads, user uploads, supply chain artifacts - switch to SHA-256. The performance difference between MD5 and SHA-256 is negligible for most applications.

Keeping legacy MD5 fields visible

Do not hide MD5 use behind a generic checksum name. Name fields md5_checksum or legacy_checksum so future maintainers can find them during audits. A visible legacy field is easier to migrate than a generic hash column that silently controls trust decisions. When a field name says "checksum" without specifying the algorithm, a future developer might assume it is SHA-256 and build security-sensitive logic on top of it without realizing the underlying hash offers no collision resistance against a motivated attacker.

In legacy migrations, preserve existing MD5 values and add SHA-256 in parallel

In existing databases, file manifests, and package repositories, MD5 checksums from before SHA-256 became standard remain alongside the content they describe. During a migration, add a sha256_checksum column rather than replacing the md5_checksum column in place. Dual-column storage lets existing consumers continue reading MD5 values while you compute SHA-256 for new entries and backfill old ones at a pace your database handles without impacting production queries.

For CSV or JSON manifests published by legacy tooling, write a migration script that re-hashes each referenced file with SHA-256 and outputs a new manifest alongside the original. Downstream consumers with MD5-only support continue using the original; newer consumers adopt SHA-256. Document the transition timeline in the manifest schema so consumers know which version to move to.

When a third-party system requires MD5, confirm the security context first

When an external service requires MD5 for a checksum or identifier field, confirm whether the context involves adversarial exposure before accepting the requirement. Internal build pipelines, file transfer between controlled systems, and cache key generation sit outside adversarial exposure: MD5 detects accidental corruption adequately in these cases. Supply chain artifacts from external sources, user-uploaded files, and any checksum used to make a trust decision all require SHA-256.

Document any MD5 usage in code comments and track it in your technical debt registry so that the migration team can find and replace these call sites when the upstream dependency is eventually updated. When the system requiring MD5 is updated or replaced, the documented usage ensures the migration team identifies and replaces the MD5 path rather than leaving it as a silent legacy.

Planning the migration path

Record which downstream system still requires MD5, who owns it, and when it can move to SHA-256. That record turns a vague legacy exception into a manageable migration item with clear accountability. Without an owner and target date, MD5 compatibility tends to persist long after the original dependency is gone. Set a concrete deadline and add a calendar reminder for the owning team, because open-ended migration items rarely get prioritized against feature work unless someone is explicitly accountable for closing them.

Try in the tool

What Is HMAC?

Because a plain hash proves nothing about who produced it, systems that need to authenticate a message's origin use HMAC¹. Anyone with the input can reproduce a SHA-256 hash - but only someone with the secret key can reproduce an HMAC¹. This single property makes HMAC the foundation of API authentication, webhook verification, and session integrity checking.

What is HMAC?

How HMAC differs from a plain hash

A plain hash depends only on the input. HMAC depends on both the input and a secret key. Consequently, two parties who share the key can both compute the HMAC for a given message and verify it matches - but a third party who sees the message and its HMAC cannot produce the same HMAC for a modified message without knowing the key. This property is called message authentication, distinct from integrity checking (which only detects changes) because it also proves the identity of the sender.

When a plain hash is not enough

Use HMAC when the verifier must know that the sender possessed a shared secret. A plain SHA-256 digest is useful for detecting accidental changes, but anyone who sees the message can compute the same digest. HMAC adds the missing authentication property without turning the message into ciphertext. The key insight is that authentication and integrity are separate concerns: a hash gives you integrity, but only HMAC or a digital signature can give you authentication, which is why protocols like webhook verification and API request signing always use HMAC rather than bare hashes.

You reach for HMAC whenever the verifier must confirm that the sender held a shared secret, not merely that the message is unchanged. A plain SHA-256 digest proves integrity, but anyone who sees the message can compute the same value without the key. CapyToolkit computes HMAC locally so you can inspect the tag format before wiring the verification step into an API or webhook handler.

Security properties and algorithm independence

HMAC's security is proven to hold as long as the underlying hash function is collision-resistant and has certain pseudo-random properties that prevent an attacker from predicting the output without knowing the key. Building on this theoretical foundation: HMAC-SHA256 inherits SHA-256's security and currently has no known practical attacks that would allow forgery or key recovery⁴. HMAC-MD5 is still considered secure for message authentication because collision resistance in the hash is not directly exploited in the HMAC construction, despite MD5's collision vulnerabilities in other contexts⁵. Yet modern designs use HMAC-SHA256 or HMAC-SHA512 exclusively, since MD5 carries reputational risk even when technically adequate for a specific use.

Common applications of HMAC

HMAC-SHA256 is the basis for most API request authentication because it provides a way to prove that a message came from a holder of the shared secret without ever transmitting the secret itself. GitHub uses it for webhook signature headers (X-Hub-Signature-256). Stripe includes it in payment event verification (Stripe-Signature). JWT HS256 tokens use HMAC-SHA256 with a server-side secret. AWS Signature Version 4 applies HMAC-SHA256 four times to derive a scoped signing key⁶. Furthermore, HMAC-SHA1 remains in legacy systems: Google OAuth 1.0, older TOTP seeds (RFC 6238 uses HMAC-SHA1 by default for time-based OTPs), and legacy HMAC-based KDF schemes.

Choosing the HMAC hash algorithm

For new systems, prefer HMAC-SHA256 unless the protocol specifies HMAC-SHA512. SHA-256 gives enough security margin for almost every application and keeps signatures shorter. SHA-512 is appropriate when a standard explicitly requires it or when long-lived keys justify the larger tag. The 64-character hex output of HMAC-SHA256 fits comfortably in most HTTP headers and log formats, while HMAC-SHA512's 128-character output can exceed header size limits in some web servers and proxies, which is a practical reason to default to SHA-256 unless you have a specific requirement for the longer digest.

HMAC key storage, minimum length, and rotation practices

Store HMAC keys in environment variables or a dedicated secrets manager rather than in source code. Embedding a key in code exposes it in version control history and to anyone with repository read access. Generate keys with a cryptographically secure random generator: os.urandom(32) in Python, crypto.randomBytes(32) in Node.js. RFC 2104 recommends a key at least as long as the hash output; use 32 bytes for HMAC-SHA256.

Rotate keys by deploying the new key alongside the old one, accepting signatures from both during a transition window, then decommissioning the old key once all tokens or messages signed with it have expired. Most JWT libraries support multiple active signing keys for exactly this rotation. Log key version identifiers in signed tokens so rotation events are auditable without exposing the secret material itself.

Because HMAC requires a shared key, it suits closed-system authentication

Because HMAC requires both parties to share the same secret, it fits closed systems where you control both the signer and the verifier. When a third party must verify your signature without a prior key exchange, use an asymmetric scheme: RSA-SHA256, ECDSA-P256, or Ed25519. JWT RS256 and ES256 tokens, TLS certificates, and software package signing all use asymmetric signatures for this reason.

HMAC is faster than asymmetric signing and requires no public key infrastructure. For internal API authentication, webhook verification, and session integrity where key distribution is fully under your control, HMAC-SHA256 is simpler and adequate. Use asymmetric signatures when you need public verifiability, certificate-based identity, or the ability to revoke trust without rotating a shared secret across all parties.

Avoiding client-side service secrets

Do not place a service HMAC key in public browser code. HMAC is appropriate in browsers only when the browser is the trusted key holder, such as a local developer tool or extension owned by the user. For public web apps, keep the secret on the server and verify signatures before processing application state. Any secret embedded in JavaScript that ships to the browser is readable by anyone who opens the developer tools, which means an attacker can extract the key and forge valid HMAC signatures for arbitrary messages, completely bypassing your authentication layer.

Try in the tool

Hash vs Encryption

Confusing hashing with encryption is one of the most common security mistakes in application development. Because both operations transform input data into an unrecognizable output, they look similar from the outside.¹ Yet the two serve fundamentally different purposes - and using one where the other is required causes serious security vulnerabilities.

What is hash vs encryption?

Reversibility: the fundamental difference

Encryption is designed to be reversible. AES-256 encryption with the right key always recovers the original plaintext. Hashing is designed to be irreversible - given a SHA-256 digest, there is no mathematical operation that recovers the original input.² This is not a limitation; it is the feature. Systems that store password hashes rely on irreversibility: even if an attacker steals the hash database, they cannot recover passwords. Conversely, using hashing instead of encryption for data that must be recovered later - user addresses, medical records, API keys that need to be displayed - results in permanent data loss.

Matching the operation to the recovery requirement

Ask whether you need the original value later. If yes, encrypt it. If you only need to compare it or prove it has not changed, hash it. That question prevents the most common design mistake before you choose algorithms, key storage, or database columns. A practical test: if a user calls support and asks you to look up their original data, you need encryption, because a hash gives you no way to reconstruct the original value regardless of how much computing power you throw at it.

You avoid permanent data loss by asking whether the original value must surface later, because that single question settles the hashing versus encryption choice. Encrypt the data when a support request might need to read it back, and hash it only when comparison or integrity is the goal. CapyToolkit computes hashes locally so you can compare digest formats without uploading the value you intend to store or transmit.

Fixed vs variable output and key requirements

Hash functions always produce the same-length output regardless of input size: SHA-256 always produces 64 hex characters, whether the input is one byte or one gigabyte. Encryption output is typically proportional to input size - encrypting a 1 MB file produces approximately 1 MB of ciphertext. Furthermore, encryption requires a key - without the decryption key, the ciphertext is unusable. Hashing requires no key (though HMAC adds a key to a hash for authentication purposes). This distinction drives the choice: hash for fingerprinting, comparison, and integrity; encrypt for storage and transmission of data that must later be recovered.

Remembering that HMAC is different again

HMAC is not plain hashing and not encryption. It adds a secret key to a hash so two trusted parties can authenticate a message. Use HMAC when you need to prove who produced the value, but do not expect HMAC to hide the message content. Think of it as a sealed envelope versus a locked box: a plain hash is like a wax seal that anyone can verify but anyone can also produce, encryption is a locked box that hides the contents, and HMAC is a seal that only someone with the right signet ring can produce, proving authenticity without hiding the message.

Common security mistakes from confusion

The most damaging confusion is storing passwords as plain SHA-256 hashes. This is not encryption - it provides no confidentiality for the password and the hash is trivially reversible using precomputed lookup tables. Building on this problem: SHA-256 is also fast (billions of hashes per second on a GPU), making brute force trivial for common passwords.¹ The correct approach for password storage is a slow, salted hash function: bcrypt, scrypt, or Argon2. A second common mistake is encrypting data and assuming the ciphertext provides integrity - AES-CBC, for example, can be modified in predictable ways without the key (padding oracle attacks).³ Authenticated encryption modes like AES-GCM provide both confidentiality and integrity.

Avoiding one-way storage for recoverable data

Do not hash values you still need to display, export, or search in plaintext form. Hashing an email address for lookup may help with indexing, but it cannot replace encryption when a support team must recover the original address for a legitimate user request. Once a value is hashed, the original is gone forever unless you stored it separately, which means any business process that requires reading the original back, such as sending a confirmation email or generating a customer report, will fail unless you planned for encryption instead of hashing from the start.

Authenticated encryption combines confidentiality and integrity correctly

AES-256-GCM and ChaCha20-Poly1305 are authenticated encryption modes that provide confidentiality and integrity in a single operation. AES-GCM computes a GHASH authentication tag over the ciphertext⁴; ChaCha20-Poly1305 uses Poly1305 as the MAC.⁵ Both modes reject modified ciphertext before decryption proceeds, preventing the padding oracle attacks that affect unauthenticated modes such as AES-CBC, where an attacker can alter ciphertext in predictable ways.

For new systems that need both encryption and integrity, choose AES-256-GCM or ChaCha20-Poly1305 as a single primitive rather than combining AES-CBC with a separate HMAC. The combined mode eliminates the ordering question (encrypt-then-MAC vs MAC-then-encrypt) that makes manual composition error-prone, and both algorithms have well-supported implementations in every major cryptographic library.

When your design needs both hashing and encryption for the same value

Some systems need to search for a specific value without decrypting every stored record. A practical pattern: hash the plaintext with HMAC-SHA256 using a server-side secret and store the result as a searchable index, then encrypt the plaintext with AES-256-GCM for storage.⁶ Equality queries compare against the HMAC index without touching the encrypted column. The encrypted column protects the original value from unauthorized access.

Using HMAC rather than plain SHA-256 for the index prevents a rainbow table attack against the indexed column, because the HMAC key adds entropy the attacker does not possess. This pattern appears in privacy-preserving databases that need to check whether a phone number or email address is registered without exposing the plaintext values to direct queries.⁷

Try in the tool