Hash Generator (MD5, SHA-256 & More)
MD5, SHA-1, SHA-256 and SHA-512 hashes of any text or file, computed locally.
This hash generator computes MD5, SHA-1, SHA-256 and SHA-512 digests of any text you type or any file you drop in. All four hashes appear together, so you can grab whichever format a checksum page, API or teammate asked for.
Hashing happens entirely in your browser. Text and files are read locally and never uploaded, which means you can hash configuration strings, license text or private documents without them leaving your machine. For large files, your device does the work, not a server.
The everyday use case is integrity checking: a download page publishes a SHA-256 checksum, you hash the file you downloaded, and if the two strings match, the file arrived intact and untampered. Hashes are also used as cache keys, deduplication IDs and quick fingerprints for comparing files.
How to generate a hash
- Type or paste text into the input box, or drop a file onto the file area.
- The MD5, SHA-1, SHA-256 and SHA-512 digests are computed automatically.
- For downloads, compare the SHA-256 output against the checksum published by the source.
- Click Copy next to the hash you need.
- Hash another file or edit the text; results update instantly.
MD5 vs SHA-256: which should you use?
MD5 and SHA-1 are cryptographically broken: attackers can construct two different inputs with the same hash. Never use them for passwords, signatures or anything security-related. They remain fine for non-adversarial jobs like detecting accidental corruption, deduplicating files or matching a legacy checksum a vendor still publishes.
For anything where tampering matters, use SHA-256 (or SHA-512). It is the standard for software checksums today. And remember a hash is one-way: it cannot be 'decrypted' back into the original data, only recomputed and compared.
A hash is one-way — you cannot decrypt it
This is the point people most often misunderstand, so it is worth stating plainly: a hash is not encryption and has no reverse operation. A hash function deliberately throws information away, squashing an input of any length down to a fixed-size digest. There is no key that turns a SHA-256 string back into the file or password it came from, and no tool, including this one, can do it.
The only way to 'reverse' a hash is to guess an input, hash it, and see if the digests match. That is exactly how leaked password databases get cracked: attackers hash billions of likely passwords and compare. It works only because weak passwords are guessable, which is why protecting passwords needs a slow, salted algorithm rather than a plain fast hash. This tool generates hashes for verification; it does not and cannot crack them.
Never use these hashes to store passwords
MD5, SHA-1, SHA-256 and SHA-512 are all fast, general-purpose hashes. Speed is a virtue for checksums but a serious weakness for passwords, because it lets an attacker try billions of guesses per second against a stolen hash. Storing user passwords as a raw SHA-256, let alone MD5, is a well-known security mistake, not a safeguard.
The correct approach lives server-side and uses a deliberately slow, salted algorithm designed for the job: bcrypt, scrypt, or argon2. These add a per-user salt and a tunable work factor so guessing is expensive even if the database leaks. Treat this tool as what it is, a way to compute and compare digests for integrity and identification, not a password-storage mechanism.
How hashing runs locally in your browser
When you type text or drop a file, the bytes are read on your device and fed through the hash functions in JavaScript, using the browser's built-in cryptography where available. The digests are computed in memory and displayed; no part of your input is uploaded, and for a file the browser reads it directly from disk rather than sending it anywhere.
That local design is why you can hash a private document or a licence file without it leaving your machine, and why large files are limited only by your own memory and CPU rather than an upload speed. It also means the tool keeps working offline once the page has loaded, since the computation never depended on a server in the first place.
Verifying downloads and checking integrity
The everyday reason to hash something is to prove it did not change. A download page publishes the SHA-256 of an installer; you hash the copy you downloaded; if the two strings match exactly, your copy is bit-for-bit identical to the original and arrived intact. A single differing byte, from a truncated download or a swapped file, produces a completely different digest, so the check is unambiguous.
The same property drives other jobs. Content-addressed systems and caches use a hash as a key so identical data is stored once. Backup and sync tools compare hashes to detect what actually changed. And support teams sometimes exchange a hash of a config or log file to confirm both sides are looking at exactly the same content without sending it back and forth.
Why two hashes differ when you expect a match
For files, a mismatch almost always means the files genuinely differ, most often because a download was incomplete or corrupted; re-download and re-hash before assuming anything worse. It can also mean you compared against the wrong published checksum, or hashed the archive when the checksum was for the extracted file.
For text, the usual culprits are invisible. A trailing newline, Windows CRLF versus Unix LF line endings, a stray leading space, or a different character encoding all change the underlying bytes and therefore the digest, even though the text looks identical on screen. When a text hash refuses to match, compare the exact bytes, not the rendered characters.
Related tools and formats
Hashing pairs naturally with the site's other converters. If you need a reversible representation rather than a one-way fingerprint, the Base64 encoder and decoder is the right tool; if you are inspecting JSON before hashing it, the JSON formatter lays it out first. It helps to remember these are fundamentally different operations: Base64 can be decoded, a hash cannot.
Digests are conventionally written as lowercase hexadecimal, which is what checksum pages publish and what you should compare against. All four algorithms here are deterministic, so the same input always yields the same string on any machine and in any conforming tool. Like every ConvertForever utility, the hash generator runs entirely in your browser, so nothing you hash is ever uploaded.
Frequently asked questions
Is this hash generator free?
Yes, free with no limits. Hash as many strings and files as you want, no account needed.
Are my files uploaded when I hash them?
No. Files are read by JavaScript in your browser and hashed on your own device. Nothing is transmitted, which is exactly what you want when hashing private documents.
Is MD5 safe to use?
Not for security. MD5 collisions are practical, so it must never protect passwords or verify untrusted content. It is still acceptable for casual checksums and deduplication where nobody is trying to attack you. Prefer SHA-256 when in doubt.
Can I reverse a hash to get the original text?
No. Hashes are one-way functions. The only way to 'reverse' one is to guess inputs and compare, which is why leaked password hashes get cracked when passwords are weak. This tool only generates hashes; it does not crack them.
Why does my hash not match the published checksum?
For files, a mismatch means the file differs, often an incomplete download. For text, watch out for invisible differences: a trailing newline, Windows vs Unix line endings, or a stray space all produce a completely different hash.
Is there a file size limit?
No fixed limit, but hashing runs on your device, so multi-gigabyte files take time and memory. Typical installers and documents hash in a few seconds.
Does the same text always give the same hash?
Yes, byte for byte. That determinism is the whole point: identical input always yields the identical digest, on any machine, in any tool.