Hash Generator

No. Cryptographic hashes are one-way functions. You can only verify by hashing a candidate input and comparing.

No. Encryption is reversible with a key; hashing is not reversible at all.

No — hashing happens locally in your browser on Toolvore.

Not for anything where someone might be trying to deceive you. Collisions — two different inputs that produce the same digest — have been demonstrated for MD5 since 2004 and for SHA-1 since 2017, so neither can any longer prove that a file or a message has not been swapped. Both remain useful where nobody is attacking you: deduplicating your own files, building a cache key, spotting an accidental change. Where the digest is standing in for trust rather than tidiness, take the SHA-256 or SHA-512 row instead.

No, and the reason is speed. A general-purpose hash is built to be fast, which is exactly what an attacker holding a stolen database wants: a graphics card can work through candidate passwords at a rate no human typing at a login form could approach, so every account with a common password falls at once. Password storage needs a function designed to be slow and memory-hungry — bcrypt, scrypt or Argon2 — with a unique random salt per user, so that two people who chose the same password do not end up with the same stored value. Hashing a password here shows you its digest; it does not make it safe to store.

Not in the way people hope, and data-protection regulators generally treat it as pseudonymisation rather than anonymisation. The trouble is the size of the input space: email addresses, phone numbers and postcodes come from a finite and guessable set, so anyone holding a list of candidates can hash every one and match the digests against yours. One-wayness protects a value with a lot of unpredictability behind it, not one that can be enumerated. Making a digest resist that takes a secret key or a per-record salt the other party does not hold — which a plain hash of the raw address is not.

That is deliberate, and it has a name: the avalanche effect. A cryptographic hash is designed so that altering a single bit of the input changes about half the output bits, with no visible relationship between the two results. It is what stops an attacker from steering the output — crafting a near-miss that slips past a comparison, or nudging an input towards a target digest. The practical consequence catches people out — a digest tells you whether two inputs match and never how close they are, so a document with one typo corrected and an unrelated document both look equally different. When you want to know what changed, compare the texts.

Nearly always because they are not hashing the same bytes. A trailing newline is the usual culprit: a text file almost always ends with one and a text box usually does not, and one extra byte changes the digest completely. After that come line endings, since a file written on Windows carries a carriage return before every newline, and character encoding, where the same visible text as UTF-8 and as UTF-16 is two different byte sequences. If a checksum will not match, compare the byte counts before suspecting the hash.

Hash the file itself, not a description of it, which means using the file hash tool rather than this one — pasting a file's contents into a text box will not reproduce its checksum. Then compare the two strings character by character, or paste both somewhere they can be diffed, because eyes are unreliable on 64 hexadecimal characters and the interesting failures differ in the middle. A mismatch means the file is not the one that was published: a truncated download, the wrong version, or something worse.