Hash Generator — SHA-1, SHA-256, SHA-384, SHA-512

What a hash generator actually does

A hash generator takes any input — text, a password, or a file — and runs it through a cryptographic hash function to produce a fixed-length string of hex characters called a digest. Change one letter in the input and the entire output changes unpredictably; feed it the same input twice and you get the exact same output every time. That combination of determinism and sensitivity is what makes hashes useful for checking that data hasn't changed.

This tool computes hashes entirely in your browser using the Web Crypto API, so the text or file you hash never leaves your device. That matters if you're hashing something sensitive like an API key or a config file — there's no upload, no server round trip, and nothing logged anywhere.

The algorithms on offer here — SHA-1, SHA-256, SHA-384, and SHA-512 — all belong to the SHA family standardized by NIST, but they differ in output length and, crucially, in how much trust you should still place in them for security-sensitive work.

SHA-1, SHA-256, SHA-384 and SHA-512 compared

SHA-1 produces a 160-bit (40 hex character) digest. It was widely used for Git commit IDs, TLS certificates, and file checksums, but it's cryptographically broken: researchers demonstrated a practical collision attack (SHAttered, 2017), meaning two different files can be crafted to produce the same SHA-1 hash. It's fine for quick, non-adversarial checks like "did this file change during a copy," but you should never rely on it where someone might deliberately try to forge a match.

SHA-256 produces a 256-bit (64 hex character) digest and is the current default for almost everything: Bitcoin's proof-of-work, TLS certificate fingerprints, package checksums (npm, pip, Docker images), and code-signing. No practical collision or preimage attack is known against it, and it strikes a good balance between security and speed.

SHA-384 and SHA-512 are part of the SHA-2 family too, built on 64-bit internal operations rather than SHA-256's 32-bit ones. SHA-512 outputs 512 bits (128 hex characters); SHA-384 is a truncated variant that outputs 384 bits (96 hex characters) and is slightly more resistant to certain length-extension considerations. On 64-bit hardware, SHA-512 can actually run faster than SHA-256 despite the longer output, which surprises people the first time they benchmark it.

None of the four are designed for hashing passwords. They're all fast by design — which is exactly the wrong property for password storage, because it lets an attacker with a stolen hash try billions of guesses per second on cheap GPUs.

Worked example: hashing the same text differently

Take the string "hello world" (no quotes, no trailing newline). Its SHA-256 hash is b94d27b9934d3e08a52e52d7da7dacefbf1a8c53c86f4dc9989a4bcac4c8fd2e — a fixed 64-character hex string, always identical for this exact input on any machine, in any language, because SHA-256 has no randomness or secret key involved.

Change one character — "Hello world" with a capital H — and the SHA-256 output becomes completely different: a01eaf... and so on, sharing no visible pattern with the original. This is the avalanche effect: a single-bit change in input flips roughly half the bits in the output. It's a deliberate design goal, not a coincidence, and it's what makes hashes useless for guessing relationships between similar inputs.

The same input hashed with SHA-1, SHA-384, and SHA-512 will each produce a completely different-looking digest of a different length, because each algorithm has its own internal structure. There is no way to convert one algorithm's output into another's — you have to rehash the original input with the algorithm you need.

Checking file integrity with checksums

One of the most common real-world uses of a hash is verifying a download. Software projects publish a SHA-256 checksum alongside an installer or archive; after downloading, you hash the file locally and compare it against the published value [1](https://emn178.github.io/online-tools/sha256_checksum.html). If the hashes match, the file is byte-for-byte identical to what the publisher built — it hasn't been corrupted in transit and hasn't been tampered with by a mirror or man-in-the-middle, assuming the published checksum itself came from a trusted source over a secure channel [3](https://go-tools.org/tools/sha-256-generator).

This is also how package managers and container registries work under the hood: npm's package-lock.json, Docker image digests, and Linux distro repositories all use SHA-256 (or similar) to guarantee that what you install is exactly what was published, not something that changed along the way.

Checksums verify integrity, not authenticity or trustworthiness. A hash confirms a file wasn't altered after the checksum was generated — it says nothing about whether the original file was safe, malicious, or from who you think it's from. For that you need a digital signature, not a bare hash.

Why you shouldn't hash passwords with SHA-256

It's tempting to think "SHA-256 is secure, so SHA-256(password) is a secure way to store passwords." It isn't. General-purpose hash functions are optimized to be fast, and modern GPUs can compute billions of SHA-256 hashes per second. An attacker who steals a database of SHA-256 password hashes can brute-force short or common passwords in minutes using rainbow tables or dictionary attacks, especially without a per-user salt.

Password hashing needs the opposite property: deliberately slow, memory-hard functions designed to resist exactly that kind of brute force. bcrypt, scrypt, and Argon2 (the current recommended default, per OWASP) all include built-in salting and configurable work factors that you tune upward as hardware gets faster. Use one of those — never a raw SHA function — for storing user credentials.

This tool is useful for verifying file integrity, generating deterministic cache keys, deduplicating content, and other non-secret use cases — not for anything where an attacker might try to reverse or brute-force the input.

HMAC and salting: why plain hashes aren't tamper-proof messages

A plain hash of a message provides integrity checking but not authenticity — anyone can recompute the same hash for a modified message, since the algorithm and input are both public. If you need to prove a message came from someone holding a shared secret, you need an HMAC (Hash-based Message Authentication Code), which mixes a secret key into the hashing process so only someone with that key can produce a matching digest.

Salting is a related but different concept, used specifically for passwords: a random value is combined with the password before hashing so that identical passwords produce different hashes across users, defeating precomputed rainbow-table attacks. A bare SHA-256 or SHA-512 call, run through this tool, has no salt and no key — it's a straightforward one-way digest, appropriate for checksums and fingerprints, not for authentication.

Common mistakes when hashing text

Invisible whitespace changes everything. A trailing newline, a stray space, or Windows-style CRLF line endings versus Unix LF will all produce a completely different hash even though the visible text looks identical. If two people hash "the same" file and get different results, this is almost always the cause — check the exact bytes, not just what's rendered on screen.

Case sensitivity is absolute. "Password123" and "password123" hash to entirely unrelated digests. If you're comparing a hash someone gave you against one you just generated, copy-paste carefully rather than retyping, and make sure you selected the same algorithm on both ends — a SHA-1 hash will never match a SHA-256 hash of the same input because they're different lengths and different math entirely.

Encoding matters too. Text is hashed as bytes, and how those bytes are produced (UTF-8 versus UTF-16, with or without a byte-order mark) affects the result for anything outside plain ASCII. For pure ASCII input like English words and numbers this is rarely an issue, but it can trip people up with accented characters or emoji.

Practical use cases beyond security

Deduplication: hashing files or records lets you detect duplicates quickly without comparing full contents byte by byte — if two hashes match, the underlying data is (for all practical purposes) identical. This is how many backup tools and content-addressed storage systems, including Git itself, decide what's already been stored.

Cache busting and content addressing: build tools often append a hash of a file's contents to its filename (app.a1b2c3.js) so browsers cache it forever until the content actually changes, at which point the filename — and hash — changes too, forcing a fresh download.

Data fingerprinting: comparing a SHA-256 of a large log file or dataset lets you quickly confirm two copies are identical without transferring or diffing the whole thing, which is handy for verifying backups or replicated data across servers.

Limits of this tool

Because hashing happens in your browser tab, very large files (multi-gigabyte) may be slow or memory-constrained depending on your device — the computation is CPU-bound and scales with input size. For everyday text, passwords, and typical file sizes this is not a practical concern.

This tool computes standard, unkeyed digests. It does not implement HMAC, bcrypt, scrypt, or Argon2, since those need a secret key or configurable cost parameters that go beyond a simple "paste text, get hash" workflow — use a dedicated library in your application code for those.