Which algorithm should I choose?

SHA-256 is the default for integrity checks and content identifiers. MD5 and SHA-1 are fast but broken for security purposes — acceptable for checksums of non-adversarial data, unacceptable for signatures or password storage.

Can a hash be reversed?

Not directly. Hashing is one-way: the same input always produces the same output, but the output contains no trace of the input. Weak or common passwords are still recovered via rainbow tables — which is why password storage needs a salt and a slow KDF.

Why does my hash differ from another tool’s output?

Check three things: the exact input bytes (a trailing newline or CRLF changes everything), the text encoding (UTF-8 vs UTF-16), and the output format (hex vs Base64). Align all three and the digests will match.

Encryption / Hash

Hash Calculator

Calculate MD5, SHA1, SHA256 and other hash values.

What is a Hash Calculator?

A hash calculator computes cryptographic hash values for text input. Hash functions convert data of any size into a fixed-size string of characters, commonly used for data integrity verification, password storage, and digital signatures.

Supported Algorithms

MD5: 128-bit hash, fast but not secure for cryptographic purposes
SHA-1: 160-bit hash, deprecated for security applications
SHA-256: 256-bit hash, part of SHA-2 family, widely used
SHA-384: 384-bit hash, higher security
SHA-512: 512-bit hash, maximum security

Use Cases

Data Integrity: Verify file downloads haven't been tampered with
Password Storage: Store password hashes instead of plain text
Digital Signatures: Ensure document authenticity
Checksums: Compare data for equality without comparing entire content

A hash calculator turns text into a fixed-length hexadecimal digest using MD5, SHA-1, SHA-256, SHA-384 or SHA-512, computed in the browser. It is used to compare checksums, derive cache keys or record identifiers, and confirm that two strings are byte-for-byte identical before signing, publishing or storing them.

Sixteen to sixty-four bytes, printed as hex

MD5 returns 16 bytes, SHA-1 returns 20, SHA-256 returns 32, SHA-384 returns 48 and SHA-512 returns 64; in hex that is 32, 40, 64, 96 and 128 characters, since one hex digit carries exactly 4 bits. The width badge next to each result is therefore character count times four — it describes the digest, never the input. The families also disagree on byte order: RFC 1321 serializes the four 32-bit MD5 state words little-endian, while SHA-1 and SHA-2 (FIPS 180-4) append them big-endian, so aligning the two hex strings byte by byte reveals nothing. And SHA-384 is not a truncated SHA-512: FIPS 180-4 gives that variant its own initial values, making it an independent digest rather than the first 96 characters of a SHA-512 output.

What actually gets hashed: untouched UTF-8 bytes

Input passes through TextEncoder, so the operands are always UTF-8 bytes: a Chinese character costs 3 bytes, an emoji 4, and Hello, DevToolbox! is 18. Nothing is trimmed or normalized on the way in; the MD5 branch converts the same string with encodeURIComponent, which is UTF-8 too. A line copied from a Windows file arrives with CRLF and changes every digest — the same 18 bytes plus a single LF hash to 8ebd64b41691362262fcc0ba289f9d86. Unicode equivalence cuts the other way: é as U+00E9 is 2 bytes (c3 a9), while e plus U+0301 is 3 (65 cc 81), so two strings that look identical hash differently unless both sides normalize to NFC first.

Why MD5 runs as JavaScript here

crypto.subtle.digest() accepts only SHA-1, SHA-256, SHA-384 and SHA-512; MD5 was never added to the Web Crypto algorithm registry, so the calculator carries its own MD5 in JavaScript and delegates the rest to the native path. That split has a visible consequence: crypto.subtle exists only in a secure context, so on plain HTTP or a file:// page only MD5 stays selectable, and the SHA checkboxes are greyed out with a notice instead of failing silently. Block sizes differ as well — MD5, SHA-1 and SHA-256 absorb 64-byte blocks, while SHA-384 and SHA-512 absorb 128-byte blocks with a 128-bit length field, which is why SHA-512 can outrun SHA-256 on long input on 64-bit CPUs.

Worked example

The three default algorithms on the built-in sample text

Input

Hello, DevToolbox!

Output

MD5      960d38443cd7112c50e31e0562eb6ba5
SHA-1    68bf5e453d6b1c7f8fd5e971ab76de80a7c7b404
SHA-256  61f8d432eb218c08b6082d0bc762c4e9c8a31af9f961cca22d8b2af4af25366a

The text is 18 ASCII bytes, so these digests match on any platform and encoding. MD5 pads to a 64-byte block with 0x80 then a 144-bit length and prints 32 hex characters; SHA-256 prints 64. Append one newline (19 bytes) and MD5 becomes 8ebd64b4…, so a mismatch usually means a stray byte, not a wrong algorithm.

Limits and pitfalls

Empty input clears the result rows instead of hashing zero bytes, so the well-known empty-string digests (d41d8cd98f00b204e9800998ecf8427e for MD5) cannot be produced here.
The uppercase switch rewrites the value that gets copied, not just the label; hex digests are case-insensitive by convention, but a string comparison in code will report a false mismatch.
There is no trimming and no newline normalization, so text pasted from an editor or a .txt file keeps its trailing CRLF and hashes differently from the same line typed by hand.
SHA-1, SHA-256, SHA-384 and SHA-512 require a secure context (HTTPS or localhost); over plain HTTP only MD5 remains, and MD5 is collision-broken, so it cannot serve as an integrity proof there.
MD5 goes through encodeURIComponent, which throws on an unpaired surrogate: pasting half an emoji blanks the MD5 row with a URIError while the SHA rows quietly hash the U+FFFD replacement bytes ef bf bd.

Related tools

Six situations, six different tools

The situation	Hash calculator on this page	What actually fits better
The bytes you care about live in a .zip, not in a paste buffer	There is no file input: the textarea only hands `inputText` to `TextEncoder`, so a binary pasted in is already replacement characters by the time the first block is absorbed, and the digest describes that damage rather than the file.	Use the File hash tool on this site — it reads `file.arrayBuffer()` and digests the raw bytes — or `shasum -a 256 archive.zip` when the check belongs in CI.
The other side must not be able to recompute the digest	A keyless digest can be regenerated by anyone who holds the text, so it proves two copies are identical and says nothing about who produced them.	The HMAC tool takes a key plus SHA-256: without that key the value cannot be reproduced, which is what webhook signatures and token checks need. Keyless for equality, keyed for authenticity.
Five hundred strings, once a month	One paste per digest, recomputed 300 ms after the last keystroke; no queue, no file list, no export, so a bulk run becomes 500 hand copies.	Loop in the shell: `printf "%s" "$line" \| shasum -a 256`. Keep `printf` rather than `echo` — `echo` appends a newline and silently changes every digest it touches.
A password column in a database	All five algorithms are a single unsalted pass, and speed is exactly why they are used for comparison — the property that makes them good here is the one that disqualifies them there.	The PBKDF2 tool derives from a password with a random salt and an iteration count you choose, or let the server use bcrypt or argon2id. No bare SHA-256 of a password should ever be stored.
A legacy column that is exactly 32 characters wide	MD5 is the only entry that prints 32 characters here — SHA-1 gives 40, SHA-256 gives 64 — and nothing on the page truncates, so the field width decides the algorithm for you.	Do not cut SHA-256 down to fill that column: the value will never equal the MD5 already stored. Match whatever the producer used; if you own the schema, widen it and record SHA-256 from the next release on.
Hashing inside your own application	This page renders values for a person to read. It exposes no endpoint and keeps no state, so a build step cannot call it.	Make the same two calls it makes: `crypto.subtle.digest("SHA-256", new TextEncoder().encode(s))` resolves to raw bytes, and you format the hex yourself.

One concrete scenario

One fingerprint field, one algorithm: filling a 40-character column

The release ticket has a fingerprint field that is 40 characters wide and uppercase only. Paste the tag build-2026-10-22 — 16 ASCII bytes — then untick MD5 and SHA-256 so only one row can be clicked, tick SHA-1 and switch uppercase on: C1B7B58FD2190734988F172C7780E161439BCE68, badged 160 bits, which is 20 bytes and exactly the width the column takes. Leave the three defaults ticked instead and the pane shows 32, 40 and 64 characters of three unrelated values; the 64-character one dropped into a 40-character field is cut by the form, not by the digest. One algorithm per field, and expect the value roughly 300 ms after you stop typing — click earlier and you copy an empty string.

Frequently Asked Questions

Which algorithm should I choose?: SHA-256 is the default for integrity checks and content identifiers. MD5 and SHA-1 are fast but broken for security purposes — acceptable for checksums of non-adversarial data, unacceptable for signatures or password storage.
Can a hash be reversed?: Not directly. Hashing is one-way: the same input always produces the same output, but the output contains no trace of the input. Weak or common passwords are still recovered via rainbow tables — which is why password storage needs a salt and a slow KDF.
Why does my hash differ from another tool’s output?: Check three things: the exact input bytes (a trailing newline or CRLF changes everything), the text encoding (UTF-8 vs UTF-16), and the output format (hex vs Base64). Align all three and the digests will match.

Content reviewed: 2026-10-22