Hash Generator: MD5, SHA-1, SHA-256 & SHA-512

What is a hash function

A hash function takes any input (a word, a document, or a certificate) and produces a fixed-length fingerprint. The same input always produces the same output, and even a single character change produces a completely different fingerprint. This property makes hashes useful for integrity verification: if two parties independently hash the same data and get the same result, the data is identical.¹

One-way, not reversible

Cryptographic hash functions are designed to be one-way, so you cannot reconstruct the original input from the hash output; this is fundamentally different from encoding such as Base64, which anyone can reverse, and from encryption, which requires a key to reverse. Approved hash functions are also expected to resist collisions, where two distinct inputs would map to the same output, and preimage attacks, where an attacker tries to find an input matching a given digest. A hash is a fingerprint, not a lock.¹

Because the output is fixed in length no matter how large the input is, two different inputs theoretically could share a digest, but for a well-designed function finding such a pair is computationally infeasible. NIST approves specific hash functions in FIPS 180 and FIPS 202 based on these properties, which is why using a current standard matters for any integrity or authentication work.

Algorithm comparison

MD5 produces a 128-bit (32 hex character) digest and was widely used in the 1990s.² It has known collision vulnerabilities (two different files can be crafted to produce the same MD5 hash), which makes it unsuitable for security-critical work.³ SHA-1 is a 160-bit algorithm with similar known weaknesses.⁴ Both are shown here for compatibility with older systems that still publish MD5 or SHA-1 checksums.

SHA-256 (256-bit) and SHA-512 (512-bit) are both part of the SHA-2 family specified by NIST's Secure Hash Standard.⁵ SHA-256 is used in TLS 1.2 cipher suites, and Git is transitioning from SHA-1 toward SHA-256 for repositories that opt into the stronger format.⁶⁷ For most new integrations, SHA-256 is the practical default; SHA-512 is useful when a system specifically requires its longer digest.

A short string makes the digest length concrete. Typing hello into the input produces the SHA-256 digest 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, a fixed 64-character hex string regardless of how short the input was. Changing a single character of the input, even capitalizing the h, produces a completely unrelated 64-character output, which is the avalanche property a well-designed hash function is expected to have.

HMAC signatures

A plain hash has no secret component, so anyone who has the input can reproduce the hash. HMAC adds a secret key to the process. The key is mixed into the hash computation in a standardized way (defined in RFC 2104), producing a digest that can only be reproduced by someone who knows the key.⁸ This is the basis for most API request authentication and webhook signature verification.

How webhook signature verification works

A typical pattern involves a server signing an outgoing webhook payload and including the resulting digest in a response header. The receiving service recomputes the HMAC using the same shared secret and the received payload, then compares the two digests. If they match, the payload is genuine and unmodified. This approach is widely used because the secret never travels with the payload, so an attacker who intercepts the request cannot forge a valid signature without knowing the key.

On this tool you can select HMAC as the mode, paste your secret into the key field, and pick an algorithm to generate a keyed digest for either an API signature or webhook verification. The usual choice for new integrations is HMAC-SHA256(payload, secret), though MD5 and SHA-1 variants are offered for compatibility when an existing service specifies one of them.

Hex vs Base64

A hash is just a sequence of bytes, but the way those bytes are written down matters every time you paste a digest into a configuration file, log message, or API header. Hex and Base64 are the two most common text encodings for binary data, and each one wins in different contexts: hex is the default for checksums and certificates, while Base64 is the standard when binary data needs to flow through text-only channels.

How the two encodings differ

Both formats represent the same underlying bytes, so neither is more or less secure; the choice is determined by what the receiving system expects. Hex uses two characters per byte using the digits 0 through 9 and the letters a through f, so a SHA-256 digest is 64 characters long.⁹ Base64 encodes three bytes as four characters from a 64-symbol alphabet, producing a shorter string; a SHA-256 digest becomes 44 characters in Base64.⁹ Because Base64 output relies on a larger symbol set in a smaller footprint, it can include padding characters when the input length is not a multiple of three bytes.

Hex is the default in most developer tools, certificates, and package managers, while Base64 appears more often in HTTP headers, JSON Web Tokens, and contexts derived from the MIME email standard.¹⁰ The HEX / BASE64 toggle on this tool re-encodes the already-computed digest client-side, so no re-hashing occurs and no fresh data leaves the browser. Matching the format that your target system publishes checksums in avoids transcription errors, especially because hex is case-insensitive while many Base64 implementations are not.

Verifying downloads with checksums

File integrity verification is the most direct application of hash functions for most developers. Software publishers post a SHA-256 hash alongside their downloads: installers, container images, and firmware binaries. After downloading, you hash the file locally and compare the result against the published value. Matching hashes confirm the file arrived intact and unmodified; a single corrupted byte produces an entirely different digest, with no resemblance to the original. Package managers such as pip can require local hashes for every package and dependency.¹¹ npm records integrity values for package-lock entries, and Cargo records SHA-256 checksums for .crate files.¹²¹³

Manual verification matters when you download directly from a vendor site rather than a package manager. Hash the file content here, select SHA-256, and compare the 64-character hex output against the value on the vendor's release page. SHA-256 is a common release-checking digest because it is specified by NIST's Secure Hash Standard and produces a digest long enough for practical comparison.⁵ Additionally, the check is binary: the hashes either match exactly or they do not.