Hash Generator

What a hash is

A hash is a fixed-length fingerprint of a piece of data. The SHA family reads any input — one character or one gigabyte, text or binary — and produces a fixed-length value: SHA-1 gives 40 hexadecimal characters, SHA-256 gives 64 hexadecimal characters, SHA-384 gives 96 hexadecimal characters, and SHA-512 gives 128 hexadecimal characters. The same input always produces the same digest, and changing even one character typically produces a very different digest. Hashes have finite outputs, so different inputs can share a digest: this is called a collision.

Hashing is not encryption. Encryption is two-way: an encrypted value can be decrypted back to the original. Hashing is one-way: there is no decryption operation that recovers the original input. The only way to "find" the input from a digest is guessing candidates and hashing them to compare, which is why weak, common inputs are easy to guess and why passwords should never be hashed with a plain fast hash.

Which algorithm to choose

SHA-1 is retained for compatibility and checksum workflows but is no longer considered collision-resistant. Whenever you can choose, use SHA-256: it is the default for a reason, it is collision-resistant for current practical purposes, and its 64-character digest is the format most tools, package managers and download pages expect.

SHA-384 and SHA-512 are the same family at larger digest sizes. They are the right choice when a standard or a partner explicitly asks for them — for example an API that publishes SHA-512 checksums. They produce longer digests (96 and 128 hex characters). Performance depends on the platform; choose the algorithm required by your workflow.

• SHA-1 (Legacy) — 40 hex chars, kept for compatibility only.
• SHA-256 — 64 hex chars, the recommended default.
• SHA-384 — 96 hex chars, for standards that require it.
• SHA-512 — 128 hex chars, for standards that require it.

How text is hashed

Text is hashed as UTF-8 bytes using the browser's standard TextEncoder. That means the same sequence of Unicode code points encodes to the same bytes on every platform.

No normalization is applied. Two strings that look identical to a human can encode to different bytes — a precomposed "é" (one code point) and a decomposed "e" followed by a combining accent (two code points) have different byte sequences and therefore different hashes. Normalizing those differences is a decision the caller should make explicitly; this tool hashes exactly the bytes your text encodes to, and says so rather than guessing.

How files are hashed

Files are hashed from their raw bytes, not from any text decoding of their contents. That is important for integrity checks: a checksum you compute on a downloaded file must match the one the publisher computed from the exact same bytes, and the raw bytes are the only fair comparison.

The file is read into the browser's memory and hashed in one pass. Two files with identical contents always produce the same digest regardless of name. Different contents will usually produce different digests, but collisions are possible.

Checksums and integrity

A checksum (or message digest) is just a hash used as a consistency check. A matching digest provides strong practical evidence that the bytes are the same when the expected digest is trusted and the algorithm remains appropriate for the use case. It is not mathematical proof: collisions are theoretically possible.

A matching checksum does not, by itself, prove authenticity. It shows that the digests match, not who produced the file. If the checksum itself came from the same attacker who tampered with the file, or if it was fetched over an unsecured channel, the match proves nothing about who produced the file. Treat checksums as an integrity check, and verify provenance through a trusted distribution channel.

• Same bytes in, same digest out — catches corrupted downloads.
• A digest does not verify a file's authenticity or its source on its own.
• Use the Compare checksum box against the value published with the file.

Hashing vs password hashing

This tool computes plain hashes with the SHA family. Those are not suitable for storing passwords or deriving keys from secrets. A fast hash like SHA-256 is easy to brute-force — an attacker can try trillions of guesses, and common passwords or dictionary phrases fall almost instantly.

Password storage needs a dedicated password-hashing or key-stretching function with a per-password random salt. Argon2 and scrypt are designed to be memory-hard. PBKDF2 is deliberately computationally expensive key stretching, not memory-hard; bcrypt also uses a configurable computational cost. Use a dedicated password-hash library for that, not this tool. This tool is for verification, fingerprints and integrity checks — for example confirming that a value matches the SHA-256 checksum an API published.

The avalanche effect

Cryptographic hashes distribute changes across the whole digest. Flipping one character — "hÇllo" instead of "héllo" — changes roughly half the output bits, so even nearby inputs produce digests that look nothing alike. With an appropriate collision-resistant algorithm, this makes hashes useful for detecting changes in practice; it is not a guarantee that collisions cannot occur.

Edge cases

An empty input is still a valid input, and its hash is not empty: SHA-256 of the empty string is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. A fixed-length digest always produces the same number of characters regardless of input length.

Whitespace matters. A trailing space or newline changes the bytes, so "password" and "password " hash differently. If you are comparing against a value from a log file or API, make sure both sides agree on the exact bytes.