How to Generate SHA-256 and Other Hashes for Text and Files

A cryptographic hash function takes an input of any size and produces an output of a fixed size, called a digest or checksum. The same input always produces the same digest, a tiny change in the input produces a completely different digest, and - critically - there is no practical way to work backward from the digest to recover the input. That last property is what makes these functions one-way, unlike encryption, which is designed to be reversed with a key.

SHA-1, SHA-256, SHA-384, and SHA-512 are all members of the Secure Hash Algorithm family, standardized by NIST. They differ mainly in digest length and internal design: SHA-1 produces a 160-bit (40 hex character) digest, SHA-256 produces 256 bits (64 hex characters), and SHA-384 and SHA-512 produce 384 and 512 bits (96 and 128 hex characters) respectively.

hello

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Hashing solves a narrow but important problem: proving that data is exactly what it claims to be, without comparing the data itself byte by byte.

• File integrity verification - compare a downloaded file's hash against the one the publisher listed to confirm nothing was corrupted or tampered with in transit.
• Content-addressable storage - systems like Git and many caches use a hash of the content as its identifier, so identical content always maps to the same key.
• Deduplication - hashing every file lets you find exact duplicates without comparing full contents pairwise.
• Deterministic fingerprints - a hash is a compact way to reference a large payload in logs, tickets, or audit trails without storing the payload itself.

Note what hashing is not for: it is not encryption, and on its own it is not a safe way to store passwords. More on that below.

Internally, these algorithms process input in fixed-size blocks through a series of bitwise operations, modular additions, and compression rounds, mixing each block into a running internal state. Once the final block is processed, that internal state is serialized as the digest. The exact mixing steps differ between SHA-1 and the SHA-2 family (SHA-256/384/512), which is why SHA-1 has known weaknesses that SHA-256 does not share.

In the browser, all of this is handled by crypto.subtle.digest, part of the Web Crypto API. Text is first UTF-8 encoded into bytes - this step matters, because two tools that encode text differently (say, UTF-8 vs. UTF-16) will produce different digests for what looks like the same string. Files are read and hashed as raw bytes, streamed in chunks so a large file does not have to be held entirely in memory at once.

1. Open the Hash Generator and type or paste text, or drop in a file.
2. Read the SHA-1, SHA-256, SHA-384, and SHA-512 digests, all computed at once and shown as lowercase hex.
3. Copy whichever digest you need for your use case.
4. To verify a checksum, paste the expected hash into the comparison field - the tool tells you immediately whether it matches the computed value.

Because text is UTF-8 encoded consistently, the digests you get will match those from sha256sum, openssl dgst, or any other correct implementation given the exact same input bytes.

• Verifying that a downloaded installer or archive matches its publisher's listed checksum.
• Generating content-addressable keys and cache identifiers from file contents.
• Creating deterministic fingerprints for deduplicating uploads or attachments.
• Producing digests to debug HMAC signatures or webhook payload verification.
• Comparing two files or strings for exact, byte-for-byte equality without a diff tool.

Treating SHA-1 as secure

SHA-1 has known collision weaknesses - researchers have demonstrated two different inputs producing the same digest. It is included for compatibility with legacy systems and non-security uses like Git object IDs, but it should not be relied on for signatures or tamper-detection where an attacker could deliberately craft a collision. Prefer SHA-256 or a stronger SHA-2 variant.

Hashing passwords with SHA-256 alone

SHA-256, SHA-384, and SHA-512 are fast by design - which is exactly wrong for password storage. A fast hash lets an attacker with a stolen database try billions of guesses per second. Password storage needs a deliberately slow, salted function such as bcrypt, scrypt, or Argon2, not a general-purpose digest.

Expecting a hash to be reversible

There is no operation that turns a digest back into its original input. Online "hash decoders" are just precomputed lookup tables for common inputs like dictionary words - they work only when the original value was weak and already known, not through any actual reversal of the algorithm.

Comparing hashes of differently encoded text

If two tools encode the same visible text differently - trailing whitespace, line-ending style, or character encoding - their hashes will not match even though the text looks identical. When a checksum comparison fails unexpectedly, check for invisible differences in the input before assuming the file is corrupted.

• Use SHA-256 as your default choice - it is fast, widely supported, and has no known practical weaknesses.
• Reserve SHA-384 or SHA-512 for cases that specifically require a longer digest, such as certain certificate or protocol requirements.
• Only rely on SHA-1 for compatibility with existing systems, never for new security-critical checks.
• Verify checksums by comparing the full digest, not just the first or last few characters - a partial match can still hide a mismatch.
• Pair hashing with Base64 encoding when you need to embed a binary digest inside JSON or a URL, and keep tokens themselves out of shared documents entirely.