Hashes
Enter text or choose a file to see its hashes.
Hashing runs entirely in your browser. Nothing is uploaded.
Enter text or choose a file to see its hashes.
Hashing runs entirely in your browser. Nothing is uploaded.
Choose the Text tab and type or paste your text, or choose the File tab and pick a file to hash locally.
All four digests β MD5, SHA-1, SHA-256, and SHA-512 β compute instantly and update as you type.
Click Copy next to any hash to place it on your clipboard.
For file integrity checks, compare the SHA-256 digest against the checksum published by the software vendor β they should match exactly.
MD5, SHA-1, SHA-256, and SHA-512 are all computed from the same input simultaneously, so you never have to switch modes to get the digest you need.
Hash arbitrary text, or drop in a file to verify its integrity. Files are read into local browser memory with the File API and never uploaded.
The SHA family is computed with the browser-native SubtleCrypto.digest() implementation β the same audited primitive used across the web platform.
MD5 and SHA-1 are clearly labelled 'not for security'. They remain useful for checksums and legacy interop, but the tool steers you toward SHA-256/512 for anything security-sensitive.
Each digest has its own copy button with visual confirmation, so grabbing a single hash is one tap β no manual text selection of a 128-character SHA-512 string.
Your text and files are hashed entirely inside your browser tab. Nothing is transmitted to a server, stored, or logged. This matters when the thing you are hashing is sensitive β a password, a private document, or a confidential file β because it never leaves your machine.
SHA-1, SHA-256, and SHA-512 use the browser's audited Web Crypto engine, and the MD5 implementation is verified against the RFC 1321 test vectors and cross-checked byte-for-byte with a reference implementation across every block-length boundary. The hashing logic is open source in tools-core.
Downloaded an ISO, a release binary, or a backup and want to confirm it arrived intact? Hash the file and compare its SHA-256 against the published checksum. A single changed bit produces a completely different digest, so the match is a strong integrity signal.
Because it is a lightweight static page with no server round-trips, it opens the instant you need it and keeps working with no network once loaded β useful on an air-gapped machine or a locked-down environment where uploading a file to an online hasher is not an option.
A cryptographic hash function takes an input of any length and produces a fixed-size string of bytes β the digest β that acts as a compact fingerprint of the data. The same input always yields the same digest, while any change to the input, however small, produces a wildly different one. Hashes underpin file-integrity checks, digital signatures, password storage, blockchains, and countless other systems. This guide explains what the common algorithms do, how they differ, and when each is appropriate.
Three properties distinguish a cryptographic hash from an ordinary checksum. Pre-image resistance: given a digest, it should be infeasible to find any input that produces it. Second pre-image resistance: given an input, it should be infeasible to find a different input with the same digest. Collision resistance: it should be infeasible to find any two distinct inputs that hash to the same value. When an algorithm's collision resistance is broken, it is no longer safe for security purposes even if it remains useful for non-adversarial integrity checks.
MD5 produces a 128-bit (32 hex character) digest and was once everywhere. It is now cryptographically broken: practical collision attacks have existed since 2004, and attackers can craft two different files with the same MD5. That makes MD5 unsuitable for signatures, certificates, or anything an adversary might attack. It is still widely used for non-security purposes β deduplicating files, verifying an accidental (non-malicious) transfer error, or interoperating with legacy systems that mandate it. This tool labels MD5 accordingly.
SHA-1 produces a 160-bit digest. Like MD5 it is broken for collision resistance β the 2017 "SHAttered" attack from Google and CWI produced two distinct PDFs with the same SHA-1 hash, and later work made such attacks cheaper. Browsers and certificate authorities have removed SHA-1 from TLS. Treat it like MD5: acceptable for legacy checksums and interop, unacceptable for new security designs.
SHA-256 and SHA-512 are members of the SHA-2 family, standardized by NIST in FIPS 180-4. SHA-256 emits a 256-bit (64 hex character) digest; SHA-512 emits 512 bits. Both remain collision-resistant with no practical attacks, and they are the workhorses of modern security: TLS certificates, code signing, Git object identifiers (migrating from SHA-1), cryptocurrency, and file-integrity verification all rely on SHA-2. For any new use where security matters, choose SHA-256 or SHA-512. SHA-512 is not "more secure" for most purposes so much as wider; on 64-bit hardware it can even be faster than SHA-256.
A frequent misconception is that hashing "encrypts" data. It does not. Encryption is reversible with a key; hashing is a one-way function with no key and no way to recover the input from the digest. You cannot "decrypt" a SHA-256 hash. What attackers do instead is guess: they hash enormous lists of candidate inputs (a dictionary or brute-force attack) and look for a matching digest. This is why hashing a password directly is inadequate β see below.
MD5, SHA-1, and even SHA-256 are designed to be fast, which is exactly wrong for password storage: speed helps attackers guess billions of candidates per second. Passwords should be protected with a purpose-built, deliberately slow password-hashing function β bcrypt, scrypt, or Argon2 β combined with a unique random salt per user. Those functions add a tunable work factor and memory cost that cripple large-scale guessing. Use the SHA family for integrity and fingerprinting, not for storing user credentials.
The most common everyday use of a hash generator is verifying a download. A vendor publishes the SHA-256 of a release; you hash the file you received and compare. Because a single flipped bit produces an entirely different digest (the "avalanche effect"), a match gives strong assurance the file is byte-identical to what was published β whether the corruption would have come from a truncated download or deliberate tampering. Prefer the vendor's SHA-256 over any MD5 they might also list.
Two related ideas often appear alongside plain hashing. A salt is a unique random value added to each input before hashing, used in password storage so that two users with the same password produce different digests and precomputed "rainbow table" lookups become useless. An HMAC (hash-based message authentication code) combines a hash with a secret key to prove both the integrity and the authenticity of a message β it answers "was this tampered with?" and "did it come from someone who holds the key?" at once, and underpins API request signing and secure cookies. Beyond these, hashes are quietly everywhere: Git names every commit and file by its hash, content-delivery networks use hashes for cache keys and subresource-integrity attributes, deduplicating backup systems store each unique block once under its digest, and blockchains chain blocks together by hash so that altering any past block would change every digest after it. Understanding what a hash guarantees β and what it does not β makes all of these systems easier to reason about.
A digest is really just a sequence of bytes; how you display it is a separate choice. This tool shows the conventional lowercase hexadecimal form, where each byte becomes two characters 0βf, so a 256-bit SHA-256 digest is 64 characters and a 512-bit SHA-512 digest is 128. Some tools instead present the same bytes in Base64, which is shorter but represents identical underlying data. When you compare a digest against a published checksum, make sure both are in the same encoding and, for hex, that letter case is ignored β AB and ab are the same byte. A mismatch caused by encoding differences is not an integrity failure; it just means the two representations were produced differently.
A hash is a fixed-size fingerprint of data produced by a one-way function. The same input always yields the same digest, and any change to the input changes the digest completely. Hashes are used for integrity checks, signatures, and deduplication.
For anything security-related, use SHA-256 or SHA-512. MD5 and SHA-1 are cryptographically broken and should only be used for non-security tasks such as legacy checksums or file deduplication.
No. Hashing is one-way β there is no key and no way to recover the original input from the digest. Attackers can only guess inputs and hash them looking for a match, which is why fast hashes are unsuitable for password storage.
Not for security. Practical MD5 collisions have existed since 2004, so it must not be used for signatures or certificates. It remains fine for non-adversarial uses like detecting accidental file corruption or interoperating with systems that require it.
Open the File tab, choose the downloaded file, and compare the SHA-256 digest shown against the checksum published by the vendor. If they match exactly, the file is intact. A single changed bit produces a completely different hash.
No. All hashing runs locally in your browser using the Web Crypto API and an in-page MD5 implementation. Your text and files never leave your device, and the tool works offline once loaded.
No. Password storage needs a deliberately slow, salted function such as bcrypt, scrypt, or Argon2. SHA-256 is fast by design, which helps attackers guess candidates quickly. Use SHA-256 for integrity, not for storing credentials.
Both are broken for collision resistance, meaning attackers can construct two different inputs with the same digest. The 'not for security' badge is a reminder to use SHA-256 or SHA-512 for anything an adversary might target.
Both belong to the SHA-2 family and are considered secure. SHA-256 produces a 256-bit digest and SHA-512 a 512-bit one. SHA-512 is wider and can be faster on 64-bit hardware; for most purposes either is an excellent choice.
Yes. Hash functions are deterministic β identical input always yields identical output. That is what makes them useful for verifying that two pieces of data are the same without comparing them byte by byte.
A plain-English guide to cryptographic hashes: how MD5, SHA-1, SHA-256 and SHA-512 differ, why MD5 is broken, and when to use each β with practical examples.
Read more →