Hash Generator

About hashing

A hash function takes any input and produces a fixed-length fingerprint of it. The same input always produces the same hash, but a hash can't be reversed back into the original data, and even a one-character change in the input completely changes the output.

The hash of a piece of text depends on its exact bytes, not just its characters — the same string encoded as UTF-8 versus UTF-16 produces two completely different hashes, even though a person reading either would see identical text. This is why file-hash tools operate on raw bytes rather than "text": there's no ambiguity to resolve. When you hash pasted text here, it's encoded as UTF-8 first, which is what almost every checksum you'll compare against also assumes, but it's worth knowing the assumption exists.

Where you'll run into it

• Verifying a downloaded file matches the publisher's checksum
• Comparing two files for equality without comparing their full contents
• Generating cache-busting keys or content-addressed identifiers
• Checking data integrity after a transfer or backup

Frequently asked

Is MD5 or SHA-1 safe for passwords?
No. Both are broken for security purposes — use a dedicated password hashing algorithm like bcrypt or Argon2 instead. These are general-purpose hashes, not password hashes.

Which algorithm should I use?
For integrity checks, SHA-256 or SHA-512 are the current standard. MD5 and SHA-1 are still common for legacy checksum verification but shouldn't be relied on for security.

Are my uploaded files stored?
No. Files are hashed on the server for that one request and then discarded.

Why does hashing the same text give a different result somewhere else?
The most common cause is character encoding: the identical-looking text produces a different byte sequence, and therefore a different hash, depending on whether it's encoded as UTF-8, UTF-16, or something else. Trailing whitespace or a different line-ending convention (\n versus \r\n) will also change the bytes invisibly. This tool hashes pasted text as UTF-8; if your comparison value came from a different encoding, the mismatch is expected, not a bug.