Hash Generator (MD5, SHA)
Generate MD5, SHA-1, SHA-256, SHA-384 and SHA-512 hashes from any text, in one click. Useful for checksums, cache keys, deduplication and verifying that two
Generate a hash from a text string or a file: MD5, SHA-1, SHA-256, SHA-384 and SHA-512. Hashes are used to verify that a download arrived intact, to compare two files without opening them, and to store a fingerprint of a value without keeping the value itself.
MD5 and SHA-1 are fast but are no longer considered secure against deliberate collisions - use them for integrity checks, not for security. For anything security-related choose SHA-256 or stronger. Hashing runs locally, so you can check a password or an API key without sending it anywhere.
How to generate an MD5, SHA-1 or SHA-256 hash
Enter text or choose a file
Pick the hash algorithm
Copy the hexadecimal digest
FAQ
Which algorithm should I choose?
SHA-256 for anything security-related, MD5 or SHA-1 only for quick integrity checks and legacy systems that require them.
Will the same input always give the same hash?
Yes, that is the point of a hash function. A single changed character produces a completely different digest.
Can I hash a file?
Yes, choose a file and its bytes are hashed directly - the standard way to verify a download against a published checksum.
Can I reverse a hash?
No. Hashing is one-way by design; the only practical attack is guessing inputs and comparing, which is why short passwords need a slow algorithm and a salt.
Is this suitable for storing passwords?
Not as-is. Password storage needs a deliberately slow algorithm such as bcrypt, scrypt or Argon2 with a per-user salt. Use the password generator for creating them instead.
Is my input uploaded?
No, the digest is computed in your browser.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Handling secrets safely
Developer tools process credentials more often than people realise, and the risk is not the algorithm but where the data goes. Hashing is one-way and is not encryption - MD5 and SHA-1 are broken for anything security-related, and even SHA-256 is the wrong tool for storing passwords, where bcrypt, scrypt or Argon2 exist precisely to be slow. Base64 is an encoding, not protection: anyone can decode it, so never treat it as obfuscation. A JWT can be read by anyone who holds it, which is why the payload must never contain secrets, and decoding a token does not verify its signature - verification requires the key. Everything on this site runs locally in your browser, which is the reason it can safely handle tokens and passwords at all.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.