a hash function takes a string of any length and produces a fixed-size fingerprint of that input. the same input always produces the same fingerprint, but a single bit changed in the input flips roughly half of the output bits. this is what makes hashes useful as integrity checks: if two computers report the same sha-256 of a file, they have the same file.
this tool reads your text, encodes it as utf-8 bytes, and feeds those bytes to the algorithm you selected. for sha-1, sha-256, sha-384 and sha-512 it uses the browser's native `crypto.subtle.digest` api, which is implemented in c or rust by the browser engine and is the same primitive used by tls and webauthn. for md5 it uses a small in-page implementation, because `crypto.subtle` deliberately does not ship md5.
the output is shown in lowercase hexadecimal by default. each pair of hex characters represents one byte of the digest. md5 produces 16 bytes (32 hex chars), sha-1 produces 20 bytes (40 hex chars), sha-256 produces 32 bytes (64 hex chars), sha-384 produces 48 bytes (96 hex chars), and sha-512 produces 64 bytes (128 hex chars). the bit count under the output is the digest length in bits.
when a project publishes a sha-256 next to a release artifact, paste the contents (or a hex sample) into this tool to compare. matching hashes mean the file has not been tampered with in transit.
apis often accept an idempotency key derived from a hash of the request body. sha-256 of the canonical request gives a stable, deterministic key that prevents accidental double-processing on retry.
static asset filenames like `app.4f3c8e9.js` are usually short prefixes of a content hash. that way the browser can cache a file forever and still pick up changes when the content (and therefore the hash) changes.
when you need to know whether two long blobs of text are identical without reading both, hash both and compare the digests. it is faster, and equal hashes are effectively a guarantee of equal content for sha-256 and above.
some older mirrors still publish md5 next to downloads. md5 is no longer trustworthy against deliberate tampering, but it remains useful for catching accidental corruption, and that is a legitimate use of this tool.
md5 and sha-1 are cryptographically broken. researchers have demonstrated practical collisions for both, which means an attacker can construct two different inputs that share the same digest. do not use md5 or sha-1 for digital signatures, code-signing, certificate fingerprints, or anything where a determined adversary might want to swap content. for those use sha-256 or sha-512.
no hash function on its own is suitable for storing passwords. hashing a password with sha-256 still leaves it vulnerable to high-throughput offline cracking with gpus or asics. password storage requires a slow, memory-hard key-derivation function such as argon2id, scrypt, or bcrypt, used together with a per-user random salt. this tool does not implement any kdf and should not be used to derive password hashes for a database.
the tool hashes utf-8 bytes of the text you paste. if you copy-paste from a rich-text editor, invisible characters such as zero-width spaces or non-breaking spaces will affect the hash even when the text looks identical. when comparing two strings, paste them into a plain editor first if you suspect formatting differences.
this widget does not hash binary files. browsers can do it via the same `crypto.subtle.digest` api, but that requires file upload, drag-and-drop and chunked reads, which are out of scope for the text-oriented version of the tool. file hashing may be added as a separate tool later.
all hashing happens locally in your browser. when you type or paste text, javascript on this page computes the digest using either the browser's native cryptographic api or, for md5, a small implementation embedded in the page. nothing is sent to a server and nothing is stored beyond the current tab.
we do not log the text you paste, the hashes you generate, or the algorithm you pick. the only network activity tied to this page is the initial load of the site itself and, if you have given consent, anonymous aggregate analytics about page views. that telemetry never includes the inputs or the outputs.
when you press copy, the digest is written to your operating system clipboard. some systems sync clipboards across devices; if your input contained sensitive data, paste the digest into its destination immediately and then clear the clipboard.
for any new use case, pick sha-256. it is fast, well-supported everywhere, and considered secure against current and foreseeable attacks. use sha-512 when you need a longer digest for higher collision resistance margins. only use md5 or sha-1 when you have to interoperate with an existing system that requires them.
yes for security purposes. collision attacks against md5 have been practical since 2004 and chosen-prefix collisions since 2008. md5 is still adequate for detecting random transmission errors in a download, but it is not adequate against an attacker who can choose the inputs.
because real-world systems still use them. continuous integration logs, package mirrors, certificate fingerprint comparisons in legacy contexts, and many hardware integration tests still rely on these algorithms. having them in this tool lets you check those without needing a separate utility.
not in this version. the tool is text-only at the moment. if you have a file, you can hash it from a terminal: on macos and linux use `shasum -a 256 file`; on windows use `Get-FileHash file`. a dedicated file-hashing tool is on the roadmap.
that is the avalanche effect, and it is a deliberate design property of cryptographic hash functions. flipping any one bit of the input flips roughly half of the bits of the output, which is what makes the digest useful as a fingerprint. a small visual change to the input is a large change to the bytes being hashed.
no. md5 always produces 128 bits (32 hex characters). sha-1 always produces 160 bits (40 hex characters). sha-256 is 256 bits (64 hex characters), sha-384 is 384 bits (96 hex characters), and sha-512 is 512 bits (128 hex characters). the count under the output box shows the exact digest length in bits.
yes. for a given algorithm and a given exact input string, the digest is always identical, on any machine and any browser. that is the whole point. if you get a different digest on a different machine for what looks like the same text, the inputs are not actually identical, usually because of invisible characters or trailing newlines.
no. hashing a password client-side does not make storage safer; the server needs to apply a slow, salted key-derivation function (argon2, scrypt, bcrypt) regardless. hashing in the browser only changes which value is the secret, not how the secret is stored. send the password over tls and let the server hash it correctly.