Loading...
Loading...
Generate SHA-256, SHA-384, and SHA-512 hashes for text and files — securely in your browser.
Use Hash Generator to create SHA-256, SHA-384, or SHA-512 digests for text and files. Hashes are one-way comparison values for integrity checks, cache keys, release verification, and change detection. They are not encryption, they cannot hide sensitive low-entropy values, and raw SHA hashes should not be used alone for password storage.
Check that the exact same bytes were hashed, including line endings, encoding, and any trailing spaces.
Look for smart quotes, hidden whitespace, different Unicode normalization, or newline differences.
Hashes cannot be decrypted, but weak or guessable inputs can still be brute-forced. Use encryption or secret storage when confidentiality matters.
Use Argon2id, bcrypt, or scrypt with salts instead of raw SHA hashes for passwords.
Hashing runs in the browser for normal text and file inputs. Avoid dropping confidential files on shared devices, and remember that hashing sensitive low-entropy values does not make them safe to publish.
Use the exact content you want to verify and avoid editing it after generating the digest.
Use SHA-256 for common checksum comparisons unless a project specifically publishes SHA-384 or SHA-512.
Match the full digest character by character and recheck line endings or file versions if it differs.
Hash an installer or archive and compare the SHA-256 digest with the value published by the maintainer.
Hash a configuration snippet before and after transfer to confirm it did not change.
MD5 is cryptographically broken — collisions can be generated in seconds. However, it's still fine for non-security uses like checksums, cache keys, and deduplication where collision resistance against adversaries isn't required.
Hashing is a one-way function: you cannot recover the input from the output. Encryption is two-way: data can be decrypted with the correct key. Use hashing for verification (passwords, integrity checks), encryption for confidentiality.
Never use raw SHA-256 or MD5 for passwords. Use purpose-built algorithms: Argon2id (recommended), bcrypt, or scrypt. These are deliberately slow and include salt to resist brute-force and rainbow table attacks.
A salt is random data added to the input before hashing. It ensures that identical inputs produce different hashes, preventing rainbow table attacks and making brute-force attacks much harder.
Generate a hash (SHA-256 recommended) of the downloaded file and compare it to the hash published by the source. If they match, the file hasn't been tampered with or corrupted during transfer.
No. Cryptographic hashes are one-way digests. You can compare a new digest with a known digest, but the tool is not designed to recover the original input from the hash value.
No. Password storage should use a slow password hashing algorithm with a unique salt, such as Argon2, bcrypt, or scrypt. General digests like SHA-256 are useful for checksums, not complete password storage.
Cryptographic hash functions are designed so small input changes produce very different output. This avalanche behavior helps detect accidental edits, copy errors, and tampering when comparing known digests.
Avoid real passwords, recovery codes, private keys, customer identifiers, and confidential documents. Even if hashing runs in the browser, sensitive source text can still be exposed through screen sharing, clipboard history, or local device logs.