DanfioSearch tools/

Type a tool name, a pinyin spelling or a synonym - both languages are searched.

Hash Generator

Global tools

Hashing is the quietest technique in computing: any text, any size, becomes a fixed, apparently random string of hex, and the same text always produces the same string while a single changed character changes every character of it. That one property makes hashes the workhorse of file checksums, cache keys, integrity checks and content identification - and the three most asked-for families are MD5, SHA-1 and SHA-256, which is why this page shows all three at once instead of making you pick first.

Hash Generator - Danfio

https://danfio.com/tools/hash-generator/ - printed from this page

Anything you type stays in this tab. The digests are recomputed on every keystroke.

Leave it blank for "hashes.txt".

Results update as you type. Nothing leaves your device.

One text, three digests

43 characters

Hashed in this tab with SHA-256, SHA-1, MD5 - 3 algorithms, computed fresh each time.

Characters
43
Algorithm names
3
Digest size
128 - 256 bits

SHA-256 (256-bit) - the one to use for checksums and signatures

d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592

No known way to produce two inputs with the same hash, which is what makes it the default choice for anything that has to be trusted.

SHA-1 (160-bit) - legacy, for old checksums and Git object names

2fd4e1c67a2d28fced849ee1bb76e7391b93eb12

Broken for security: a collision can be produced deliberately, so it is a checksum and not a signature. Git still uses it to name objects, and this page will still compute it for that.

MD5 (128-bit) - legacy, for ETags and file deduplication

9e107d9d372bb6826bd81d3542a419d6

Broken for security since 2004. It survives as a non-adversarial checksum: S3 ETags and a lot of data pipelines are built on it, and a mismatch still means a different file.

What the numbers do not say

  • Hashing is one-way: from the digest you cannot recover the text, which is the point. "Verifying" means hashing again and comparing the hex, not decoding anything back.
  • SHA-256 is the one to choose for anything new. SHA-1 is legacy but still everywhere (Git object names); MD5 is legacy and now easy to collide, so it is here for old systems that expect exactly 32 hex characters.
  • An identical text always produces the identical digest, so each hash works as a checksum - but for a password, use a slow password hash (PBKDF2, scrypt, bcrypt) with a salt instead of any of these.
The text and the digests were computed in this browser tab: nothing was uploaded, nothing was sent, and nothing was stored.

The three are not equals, and the page says so rather than letting you guess. SHA-256 is the one to choose for anything new. SHA-1 is older but still everywhere: Git names its objects with it. MD5 is older still and now easy to collide, yet plenty of legacy systems still ask for exactly its 32 hex characters. Hashes computed here never leave the tab - the box holds the plain text, the three digests appear beside it, and typing is recomputed live.

About this hash generator

This is a one-way transform, not a code: from the digest you cannot recover the text, and no page, however clever, can reverse it. That is the point of a hash, and it is also why verifying a stored secret is done by hashing the candidate and comparing the result rather than decrypting anything. The three algorithms here are fixed in the page itself, with nothing outside the page that could drift, so the same text gives the same hex on every machine and in the built-in example.

If the text you want to protect is a password, one of these fast hashes is not the final answer: they are designed to be quick, which is exactly what an attacker wants. Real password storage uses a deliberately slow, salted scheme like PBKDF2, scrypt or bcrypt. This page keeps MD5, SHA-1 and SHA-256 because files, caches and legacy systems actually ask for them - not because they are the right way to store a secret.

How this hash generator works

What a digest is, and why the same text gives the same string

A hash function takes any input and folds it into a fixed-size digest: 32 hex characters for MD5 (128 bits), 40 for SHA-1 (160 bits), 64 for SHA-256 (256 bits). The function is deterministic - the same bytes always produce the same digest, which is what makes a hash usable as a checksum - and it is one-way, which is what makes it usable for storage without keeping the original around.

It is also avalanche-heavy by design: change one character, or one byte, and the digest changes completely rather than by an obvious nearby amount. That is why an identical comparison is a strong signal that two files are byte for byte the same, and why a hash is a poor way to store structured data: there is no way back from it.

The page recomputes the digests on every keystroke in the tab, so the avalanche effect is visible live: change one character of the input and every character of all three outputs changes. It also prints how many characters were hashed, so the size of the input a digest describes is on the page rather than implied.

MD5, SHA-1 and SHA-256: which one and why

SHA-256, part of the SHA-2 family, is the current default and the safest of the three for anything new - file checksums, deduplication, integrity checks. SHA-1 is a legacy algorithm still in constant use because Git names its objects with SHA-1; it should not be used for security boundaries anymore, but it remains correct for content identification. MD5 is the oldest and now demonstrably easy to collide - two different messages can be made to produce the same digest - so it is here for the legacy systems that expect exactly 32 hex characters, and nothing else.

Choosing is the whole point of showing three: an identical text also produces the identical SHA-256, so you can verify a download by hashing it here and comparing it to the published checksum - the comparison is the verification, and a hash solves nothing by being secret.

For a password, none of these fast hashes is the final answer: they are built to run quickly, which is exactly what an attacker wants, so stored secrets use a slow, salted scheme such as PBKDF2, scrypt or bcrypt. This page keeps the three because files, caches and legacy systems ask for them, not because they are how to store a secret.

Verifying a download, character by character

Checking a file against a published checksum is three steps: hash the file you downloaded, read the digest the vendor published, compare the two strings character by character. This page hashes text you paste, not a file on disk - so the honest workflow is to run `sha256sum` (or `Get-FileHash` on Windows) on the file, then paste the result here to see what such a digest looks like.

The comparison is exact, and whitespace counts. Copying a digest out of an HTML page often drags a line break or a non-breaking space along with it, which is why a mismatch on the first or last character is worth re-copying before it is worth worrying about.

A digest proves the bytes arrived as they left; it says nothing about who sent them. That is what a signature adds - and it is why a checksum hosted on the same server as the download protects against corruption, not against someone who can rewrite both.

Worked examples

Each example below was run through the calculator on this page when the site was built, so the numbers match what you see when you enter the same inputs.

The classic test sentence

Text to hash: The quick brown fox jumps over the lazy dog

One text, three digests

43 characters

Hashed in this tab with SHA-256, SHA-1, MD5 - 3 algorithms, computed fresh each time.

Characters: 43 · Algorithm names: 3 · Digest size: 128 - 256 bits

A well-known sentence with published digests, so you can compare this page against another hash tool byte for byte.

Two strings that differ by one word

Text to hash: password

One text, three digests

8 characters

Hashed in this tab with SHA-256, SHA-1, MD5 - 3 algorithms, computed fresh each time.

Characters: 8 · Algorithm names: 3 · Digest size: 128 - 256 bits

Typing “password1” instead changes every character of all three digests - the avalanche effect, visible live as you type.

Frequently asked questions

Can a hash be reversed?

No. Hashing is one-way, and no computation can recover the text from the digest. What attackers actually do to weak material is guess: hash a dictionary of likely inputs and compare, which is why a short password is easy to find even when it was hashed - not because the hash was reversed but because the candidate list is short. The defense is not a stronger hash but a slow one with a salt, which is why passwords should use PBKDF2, scrypt or bcrypt instead of any of these.

Is my text sent anywhere?

No. Everything is computed in this tab, on every keystroke, and there is no request behind the page. The download is a blob built locally, and nothing is stored - so a password or a config secret that you paste here never leaves the machine.

Why do the three digests have different lengths?

Because they are different sizes of output: 32 hex characters for MD5 (128 bits), 40 for SHA-1 (160 bits) and 64 for SHA-256 (256 bits). A longer digest is one a collision is harder to find in, which is the practical difference between them beyond the number itself.

Which hash should I use, and where?

For anything new, SHA-256. For verifying a download against its published checksum, use the algorithm the checksum names - some software still publishes SHA-1 or MD5 out of habit. For password storage, none of these: use a slow, salted password hash such as PBKDF2, scrypt or bcrypt.

Why does the page include MD5 and SHA-1 if they are broken?

Because they are everywhere. Git names objects with SHA-1 and will for years; legacy integrations still accept exactly 32 MD5 hex characters. “Broken” here means unsuitable for security boundaries like signatures and certificates - not unusable for content identification, which is what most people asking for a hash actually need.

Assumptions and sources

  • MD5, SHA-1 and SHA-256 follow their published specifications (RFC 1321 and FIPS 180-4), including the digest lengths the standards define.
  • SHA-1 and MD5 are offered for checksums and legacy systems only; the page says plainly that neither is safe for security or for passwords.
  • Hashing happens in your browser: the text never leaves the tab and is not stored.

Last reviewed 2026-10-07. Runs locally on your device; keep backups; no financial advice applies. Read the full disclaimer.

Where a figure on this page comes from an official agency — HUD, IRS, FICO or a state body — the site keeps a dated snapshot of the source page in its sources library, and a scheduled job re-checks that snapshot, so the number can be traced back to the document it came from.

Related tools

Base64 Encoder & DecoderDeveloper ToolsEncode text to base64 or decode it back, in your browser, with the standard and URL-safe alphabets, UTF-8 handled properly, percent-encoding and data URLs too.Encode or decode Base64 →JWT Decoder & Hash GeneratorDeveloper ToolsDecode a JSON Web Token and see what every claim means, check an HS256 signature against a secret, and hash text with SHA-256, SHA-1 or MD5 in the browser.Decode a JWT →UUID & Random String GeneratorDeveloper ToolsGenerate version 4 and version 7 UUIDs and random strings in your browser, and check UUIDs you already have: version, variant, timestamp and MAC address.Generate UUIDs →JSON Formatter & ValidatorDeveloper ToolsPaste JSON and get it formatted, minified or sorted, with the line and column when it is broken plus hints for the four mistakes everyone makes. No upload.Format and validate JSON →Color ConverterDeveloper ToolsConvert between hex, rgb() and hsl() in your browser: paste one color, get all three formats and an sRGB channel preview.Convert hex, rgb and hsl →Cron Expression GeneratorDeveloper ToolsTurn a cron expression into plain English and the next run times: five fields or six, Vixie or Quartz, in any time zone, with the traps named. No upload.Build a cron expression →