Text Hash Generator
Generate text hashes online with MD5, SHA-1, SHA-2, SHA-3, and RIPEMD-160, add optional salt rules, and save or copy digests for checks and records.{{ hashSummaryTitle }}
| # | When | Input (chars) | Type | Case | Salt | Digest | Copy |
|---|---|---|---|---|---|---|---|
| {{ i+1 }} | {{ formatWhen(r.ts) }} | {{ r.input_len }} | {{ r.hash_type }} | {{ r.uppercase ? 'UPPER' : 'lower' }} | {{ r.salt ? r.salt + ' (' + r.salt_position + ')' : '-' }} | {{ r.digest }} | |
| No entries yet. Use Save to add the current digest. | |||||||
| Profile field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
Introduction
Cryptographic hashes turn text of any length into fixed-size digests. They matter when the question is exact sameness: did a copied command, note, token, or short message stay identical after it moved from one person or system to another?
That answer is narrow, but it is useful. If two people hash the same text with the same algorithm and the same salt rule, they get the same digest. Change one letter, one line break, one space, or the salt position, and the digest changes.
A digest match does not prove authorship, trust, or safety. It only shows that the compared input produced the same fingerprint under the same rules. That is enough for integrity checks and recordkeeping, but not enough to replace signatures, authenticated delivery, or careful review of the original text.
Older digests such as MD5 and SHA-1 still appear in legacy checklists and compatibility workflows. For new trust-sensitive work, current guidance favors SHA-2 or SHA-3 instead.
Technical Details:
A cryptographic hash function maps a message to a fixed-length digest and is designed so small input changes produce a very different result. For security use, the classic goals are collision resistance, preimage resistance, and second-preimage resistance. FIPS 180-4 defines the SHA-1 and SHA-2 families, while FIPS 202 defines the fixed-length SHA-3 family. The supported set spans MD5, SHA-1, SHA-2, SHA-3, and RIPEMD-160, which covers current standards as well as several older compatibility paths.
Text hashing is exact and order-sensitive. The characters are hashed as written, so whitespace and line breaks matter. A salt is not blended in abstractly; it simply becomes extra text. Prefix salt means salt plus text. Suffix salt means text plus salt. The same salt in a different position is a different input.
The rule can be written compactly as follows.
Digest length is a quick diagnostic. A 128-bit digest appears as 32 hexadecimal characters, 160 bits as 40, 224 bits as 56, 256 bits as 64, 384 bits as 96, and 512 bits as 128. If a reference digest has a different length from the result you see, the first thing to suspect is the selected algorithm rather than a subtle text mismatch.
| Hash type option | Summary badge | Digest bits | Hex characters | Practical reading |
|---|---|---|---|---|
| MD5 | MD5 |
128 | 32 | Legacy compatibility and accidental-change checks only. |
| SHA-1 | SHA1 |
160 | 40 | Legacy compatibility path; not a good choice for new trust-sensitive fingerprints. |
| SHA-2-224 | SHA224 |
224 | 56 | Shorter SHA-2 variant when an existing workflow names it. |
| SHA-2-256 | SHA256 |
256 | 64 | Usual broad-compatibility default for new digest sharing. |
| SHA-2-384 | SHA384 |
384 | 96 | Longer SHA-2 digest when a policy or peer asks for it. |
| SHA-2-512 | SHA512 |
512 | 128 | Longest SHA-2 option in the current set. |
| SHA-3-224 | SHA3-224 |
224 | 56 | Fixed-length SHA-3 option when SHA-3 is explicitly required. |
| SHA-3-256 | SHA3-256 |
256 | 64 | Common SHA-3 size for new records that call for SHA-3. |
| SHA-3-384 | SHA3-384 |
384 | 96 | Longer SHA-3 digest. |
| SHA-3-512 | SHA3-512 |
512 | 128 | Longest SHA-3 option in the current set. |
| RIPEMD-160 | RIPEMD160 |
160 | 40 | Compatibility option for older systems that still specify it. |
| Change or setting | Does the digest change? | Why |
|---|---|---|
| Text characters change | Yes | The underlying message changed. |
| Hash type changes | Yes | A different hash family is being applied. |
| Salt is added or removed | Yes | The hashed input is no longer the same text. |
| The same salt moves from prefix to suffix | Yes | Order matters, so the combined string changes. |
Uppercase is toggled |
No | Only the displayed hexadecimal letter case changes. |
MD5 and SHA-1 still matter when you must reproduce old digests, but they are poor choices for new trust-sensitive work. RFC 6151 says MD5 is not prudent when collision resistance is required, and NIST has an active plan to remove SHA-1 from the secure hash standard. NIST continues to approve SHA-2 and fixed-length SHA-3, so SHA-256 or SHA3-256 are the safest defaults when no outside system has already chosen the algorithm.
Everyday Use & Decision Guide:
For a plain text fingerprint, leave Hash type on SHA-2-256, keep Salt empty, and paste the exact text into Text. The page opens on the empty-string starting state, so the Digest box is already visible. As soon as you type or paste real content, the digest updates instantly, the algorithm badge reads SHA256, and the result becomes a normal 64-character fingerprint you can copy into a note or ticket.
Change the algorithm only when you are matching a digest someone else already published. If an older checklist says MD5, SHA-1, or RIPEMD-160, reproduce that family for the comparison and decide separately whether your workflow should move to something stronger. A different algorithm is not a better comparison. It is a different digest.
- Use
Saltonly when everyone involved knows the exact salt text and whether it isPrefixorSuffix. TheRandombutton creates a 16-byte salt shown as 32 hexadecimal characters. - Use
Savewhen you want a local comparison trail. TheTabletab lets you review multiple runs without retyping every case. - Turn on
De-duplicate by digestwhen repeat runs clutter the list and you only care about unique results. - Check
Digest Profilewhen a comparison feels wrong.Digest characters,Input characters, andSalt modeoften explain the mismatch quickly.
The JSON tab is useful when you need a structured record without carrying the original text forward. It includes the current settings, the current Digest, a history summary, and any saved rows, but it does not store the raw text itself.
Most false mismatches come from hidden whitespace or an unrecorded salt rule. Before you trust a match, read the badges above the digest and make sure algorithm, salt state, and casing are exactly what you intended.
Step-by-Step Guide:
A normal comparison run is short once you know where the checks live.
- Paste or type the target text into
Text. The summary box is already on screen, and theDigestvalue should change immediately as the text changes. - Pick
Hash type. For a fresh general-purpose fingerprint,SHA-2-256makes the summary badge readSHA256and produces a 64-character digest. For reproduction work, choose the exact family named by the other side. - Open
Advancedonly if the workflow needs it. AddSaltor pressRandom, choosePrefixorSuffix, and useUppercaseonly if display style matters. The digest should change immediately when the salt text or salt position changes. - Use
Copywhen you only need the latestDigest. UseSavewhen you want the current run added toTable; the button changes toSaved!when the row is recorded. - Open
Tableto compare runs. If you only care about unique digest values, enableDe-duplicate by digest. UseCopy CSV,Download CSV, orExport DOCXwhen you need a local record. - Open
Digest ProfileorJSONwhen you need context.Digest Profileshould showDigest characters,Input characters, andSalt mode.JSONcan be copied or downloaded for structured notes. - If a comparison does not match, fix the most common causes in order: hidden whitespace in
Text, wrongHash type, missing or extraSalt, then wrongSalt position. Recheck the summary badges before saving the corrected run.
A comparison is ready only when the Digest text and the summary badges reflect the exact rules you meant to apply.
Interpreting Results:
The result to trust is the combination of the Digest value and the badges next to it. A hex string by itself is incomplete. The same text can produce very different digests under a different family or salt rule.
| What you see | What it means | What to do next |
|---|---|---|
| Exact digest match, same algorithm badge, same salt rule | The compared text is the same under the same hashing rules. | Treat it as a valid identity check and compare it against a trusted reference. |
| Same letters, only uppercase or lowercase differs | The digest value is still the same. | Treat it as a match unless your documentation requires one display style. |
Different digest and different Digest characters |
You are almost certainly using a different hash family. | Set the same Hash type before deciding the text changed. |
Different digest with the same length but different Input characters or Salt mode |
The text or the salt rule changed even if the text looks similar. | Check whitespace, line endings, salt text, and salt position. |
| Matching MD5 or SHA-1 digest | You reproduced the same text under a legacy family. | That is fine for compatibility, but it is not a reason to keep using those families for new trust-sensitive records. |
Do not overread a match. It does not prove authorship, secrecy, or safety. When the stakes are high, verify that the reference digest came from a trusted channel and prefer SHA-2 or SHA-3 for new records.
Worked Examples:
A deployment note with a modern default
Put build-2026-04-11 into Text, leave Salt empty, and keep Hash type on SHA-2-256. The Digest becomes 685a595785d5d8c892d1b4e7bf221da392360cc8472254182e72fd516c94b59e. In Digest Profile, Digest characters reads 64, Input characters reads 16, and Salt mode reads No salt. That is a clean modern fingerprint for a change log or handoff note.
The same salt in a different position
Put customer-4471 into Text, set Hash type to SHA-3-256, and enter stage as the Salt. With Salt position on Prefix, the Digest is b255686c5195d660a33ab9d7d8704fbf357e791b3625ec48ff34f5db27375160. Switch to Suffix, and the Digest changes to 437896a064a5a391eeb5da7590a8d38093d1b91c7c02379b3a71538959f4ef58. Digest characters stays at 64 because the algorithm did not change, but the digest changes because the combined text changed from salt-plus-text to text-plus-salt.
A hidden newline that breaks a comparison
With Text set to api-key-prod, Hash type on SHA-2-256, and no salt, the Digest is 7932f43b4531d71770d1cb7341c686cb96650bfafab01a086b69181c487801ec. If a pasted newline slips in at the end, the Digest becomes 7925a3081bc8af2c0a848d580697088fbe8e517b5ba95e665318d9ea04a1b618. The fastest clue is in Digest Profile: Input characters rises from 12 to 13 even though the visible text may look the same. Remove the extra newline and rerun before treating the mismatch as a real content change.
FAQ:
Why did my digest change when the text looked the same?
The usual causes are invisible whitespace, a different line ending, the wrong Hash type, or a different salt rule. Check the summary badges first, then open Digest Profile and compare Input characters, Digest characters, and Salt mode.
Why do I see a digest before I type anything?
The page starts on the empty-string case with SHA-2-256 selected, so it already has a valid digest to show. That starting digest is only for blank text. Save stays disabled until Text contains at least one character.
Does Uppercase change the actual hash?
No. It only changes how the hexadecimal letters are displayed. The underlying digest value stays the same, which is why uppercase and lowercase versions still compare as a match.
Should I choose MD5, SHA-1, or SHA-256?
For new trust-sensitive work, use SHA-2 or SHA-3. For reproduction work, use the exact family already named by the existing record, even if it is MD5 or SHA-1. Matching the published method matters more than picking the newest option.
Does my text leave the browser?
The hashing itself happens in the current browser session, and saved rows stay in local browser storage until you clear them. The page does load its hashing library from a CDN when it opens, but the text you hash is not sent to an application server by this tool.
Can I use this for password hashing?
No. This page applies one fast hash plus an optional concatenated salt. It does not provide password-specific protections such as work factors or memory hardness. Use a dedicated password-hashing system instead.
Responsible Use Note:
Use this page for digests, reproducible fingerprints, and compatibility checks. Do not treat a digest match as proof that text is authentic, approved, or safe to execute. If you need authenticity, use digital signatures or a keyed message authentication method. If you need password storage, use a password-specific hashing system rather than a single fast digest.
Glossary:
- Digest
- The fixed-length fingerprint produced from the text.
- Collision resistance
- The difficulty of finding two different inputs that produce the same digest.
- Preimage resistance
- The difficulty of recovering an original input from its digest alone.
- Salt
- Extra text added before or after the original text before hashing.
- Hexadecimal
- Base-16 text using 0-9 and a-f, where each byte is represented by two characters.
References:
- Secure Hash Standard (FIPS 180-4), National Institute of Standards and Technology, August 2015.
- SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (FIPS 202), National Institute of Standards and Technology, August 2015.
- NIST Transitioning Away from SHA-1 for All Applications, National Institute of Standards and Technology, December 15, 2022.
- RFC 6151: Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms, IETF, March 2011.