A hash function takes any input and returns a fixed-length fingerprint: change one character and the fingerprint changes completely; feed in the same text twice and you get the same fingerprint twice. That one-way property is what makes hashes useful for verifying downloads (compare the published checksum against your file), storing passwords (services store the hash, never the password), and fingerprinting data in version control. SHA-256 is the current workhorse — fast, universally supported, and with no practical attacks. SHA-512 is its larger sibling for contexts that want a longer digest. SHA-1 is included only for verifying legacy checksums; it is broken for collision resistance and must not be used for anything security-sensitive. One thing a text hashing tool cannot do: hash a file. Checksums for downloads are computed over file bytes, so use a dedicated file checksum tool for that job.
What hashing is and is not
Hashing is not encryption. Encrypted data can be decrypted with the key; a hash cannot be reversed, by design, no matter how much computing power you throw at it. It is also not compression — the output reveals nothing about the input's length or content. What it gives you is a compact, deterministic fingerprint: equal inputs always produce equal hashes, and unequal inputs produce different hashes with overwhelming probability. That makes it the right primitive for integrity checks and the wrong one for secrecy.
Which algorithm to pick
For verifying a published checksum, use whichever algorithm the publisher used — the names must match exactly or the comparison is meaningless. For new uses, SHA-256 is the default choice: supported everywhere from browsers to databases, fast enough for any interactive use, and trusted. SHA-512 is marginally faster on 64-bit servers and produces a longer digest, worth considering for bulk server-side hashing. SHA-1 survives only for compatibility with old checksums; generating new SHA-1 hashes for security purposes is negligent.
Why this tool runs locally
Hashing your text on a server would mean transmitting the very data you may be trying to protect — an API key you want to fingerprint, a password you want to check against a breach list. This page computes the digest with the Web Crypto API inside your browser tab, so the input never leaves your device. You can verify this yourself: open the tool, disconnect from the network, and it keeps working.
How to use
- Type or paste your text into the input box.
- Pick an algorithm: SHA-256 for general use, SHA-512 for longer digests, SHA-1 only for legacy checksums.
- Copy the resulting hex digest.
- Compare it against the expected value, if you have one.
Frequently asked questions
Is it safe to paste sensitive text here?
Yes. The digest is computed locally in your browser via Web Crypto and nothing is transmitted. The tool keeps working with the network disconnected, which you can test.
Why is there no MD5 option?
MD5 is broken for collision resistance and the Web Crypto API deliberately does not offer it. Offering MD5 would suggest it is still acceptable for security uses, which it is not.
Can two different texts produce the same hash?
In theory yes — that is called a collision. In practice, for SHA-256 and SHA-512 no collision has ever been found, and none is expected within any realistic computing budget.
Can I hash a file, not just text?
Not with this tool — it hashes the text you type. File checksums are computed over raw bytes; use a dedicated file checksum utility for verifying downloads.