Hash Generator — Manual

Back to the overview: Hash Generator · Open the tool live: www.jpkc.com/tools/hash/

This manual covers the Hash Generator in full: text hashing with every algorithm, HMAC, output formats, comparison and SRI, file hashing, and the section for password hashes. Field and button names are given exactly as they appear in the tool.

Layout of the interface

The tool is split into three tabs:

Text — on the left the Input field with its input encoding and the optional HMAC key; on the right the compare field, the Output format, and the result table with every algorithm.
File — on the left the drop area, the algorithm selection, and the progress bar; on the right the compare field and the result table.
Password hashing — on the left Create a hash (bcrypt, Argon2id, PBKDF2), on the right Verify a password (check a stored hash).

Switch tabs by clicking or with the ← and → arrow keys. The tool remembers the tab you used last. A fragment in the URL opens a tab directly: #text, #file, or #password (e.g. https://www.jpkc.com/tools/hash/#password) — such a fragment takes precedence over the remembered tab. Below all tabs sits the footer with the history switch (see History and storage).

Text hashing

Input and flow

Type or paste your text into the Input field (placeholder "Type or paste text — all hashes update live"). The table on the right updates live — shortly after each keystroke (with a delay of about 120 ms) all 20 hashes are recomputed. There's nothing to click. Even with an empty field the table shows the hashes of the empty input, and the info line below the field says so: "hashes of the empty input".

The info line also gives the size of the input in bytes (or KB/MB) and, if set, the length of the HMAC key ("HMAC key N bytes"). Decoding errors show up in the same spot in red.

Input encoding

The selector above the field, on the right, decides how the tool turns your input into bytes:

Text (UTF-8) (default) — the tool hashes the UTF-8 bytes of the text exactly as it stands in the field. The field always delivers line breaks as \n (LF), even if you paste text with \r\n (CRLF). For CRLF content, use Hex bytes or the File tab.
Hex bytes — the input is a sequence of hex bytes. 0x and \x prefixes are ignored, as are spaces, line breaks, :, ,, and - used as separators. Invalid characters or an odd number of digits are reported as "Not hex: …".
Base64 bytes — the input is Base64. Whitespace doesn't matter, the URL-safe alphabet (-, _) is accepted, and the = padding may be omitted. Errors are reported as "Not Base64: …".

That lets you hash binary data you only have as a hex dump or a Base64 string.

Output encoding

The Output selector above the table sets the format of every value:

hex — lowercase hexadecimal (default).
HEX — uppercase hexadecimal.
Base64 — standard Base64 with = padding.
Base64URL — the URL-safe variant (- and _), without padding.

The tool remembers your choice. It also applies to the table in the File tab, even though the selector itself only lives in the Text tab. Each table row has its own Copy button that puts the value on your clipboard in the currently selected format.

The algorithms in detail

The table always shows all 20 algorithms, grouped into four blocks. A tooltip on the name explains any peculiarities. Hex lengths refer to the hex format.

Legacy (not collision-resistant)

MD5 — 128 bits, 32 hex characters. Cryptographically broken (collisions are practical to produce). Use only as a checksum against accidental change.
SHA-1 — 160 bits, 40 hex characters. Also broken; for compatibility only.
RIPEMD-160 — 160 bits, 40 hex characters.
CRC-32 — 32 bits, 8 hex characters. The IEEE 802.3 checksum used by zip, gzip, and PNG — in the words of the tooltip, a "checksum, not a cryptographic hash".

SHA-2

SHA-224 — 56 hex characters.
SHA-256 — 64 hex characters. Today's standard for file integrity.
SHA-384 — 96 hex characters.
SHA-512 — 128 hex characters.
SHA-512/256 — the variant of the SHA-512 family truncated to 256 bits; 64 hex characters.

SHA-3 (FIPS 202)

SHA3-224, SHA3-256, SHA3-384, SHA3-512 — the standardized SHA-3 family as defined in FIPS 202 (56, 64, 96, and 128 hex characters).
Keccak-256, Keccak-512 — the original Keccak with its pre-standardization padding. Keccak-256 is the algorithm Ethereum uses. For the same input it produces different values than SHA3-256.
SHAKE128 (256-bit output, 64 hex characters) and SHAKE256 (512-bit, 128 hex characters) — extendable-output functions (XOFs); the tool outputs them at these fixed lengths.

A note on old values: earlier versions of the tool actually output Keccak under the label "SHA-3". A SHA-3 value you computed here before the rebuild therefore won't match today's SHA3 result. An old SHA3-256 or SHA3-512 value (including one from the file section) reappears in the Keccak-256 or Keccak-512 row. For old SHA3-224 and SHA3-384 values, today's tool has no counterpart.

BLAKE

BLAKE2b-512 — 128 hex characters.
BLAKE2s-256 — 64 hex characters.
BLAKE3 — default output of 256 bits, 64 hex characters.

HMAC — keyed authentication

HMAC stands for Keyed-Hash Message Authentication Code. Unlike a plain hash, HMAC combines the message with a secret key — so you can verify not only that a message is unchanged, but that it came from someone holding the key (authenticity). Typical uses: API request signatures and webhook verification.

How to use it:

Enter your key in the HMAC key field (labeled "optional — shows HMACs instead of plain hashes" in the tool).
Next to it, pick the key's encoding: Text, Hex, or Base64. A webhook secret given as plain text stays on Text; a key delivered as hex or Base64 is decoded and used as raw bytes.
The table immediately switches from plain hashes to HMACs — every affected row carries an HMAC badge.

HMAC is available for every algorithm except SHAKE128, SHAKE256, BLAKE3, and CRC-32. With a key set, these four rows keep showing the plain hash and carry a plain badge ("No HMAC for this algorithm"). As long as a key is entered, the SRI line is hidden. Clear the field and the table goes back to plain hashes.

Random key (dice button)

The button with the dice icon next to the key field ("Generate random key") creates a 256-bit random key (32 bytes) with the browser's cryptographic random number generator (crypto.getRandomValues), fills it in as 64 hex characters, and switches the key encoding to Hex. The key is generated entirely locally; no server call is involved.

Comparing with an expected hash

Above the table is the field "Paste an expected hash to compare…". Paste a value there and the tool looks for a match across all rows:

If an algorithm matches, its row is highlighted in green and a line above reads "Match:" followed by the name (with "(HMAC)" appended for HMACs). As a side effect, that tells you which algorithm produced an unknown hash.
If nothing matches, the tool says "No algorithm produces this hash."
If the value can't be read as hex or Base64, you get "Not a hex or Base64 hash."

The field understands several notations: hex in upper or lower case, also with colons (AB:CD:…), Base64 and Base64URL, SRI values with their prefix (sha256-…, sha384-…, sha512-…), and whole lines from sha256sum and friends in the form hash filename — in that case only the hash before the first space counts. The comparison works independently of the selected output format.

Subresource Integrity (SRI)

As long as no HMAC key is set, an SRI line appears below the table with the integrity value of the input, preferably as sha384-… (the Base64 of the SHA-384 hash). The Copy button next to it copies the complete attribute pair:

integrity="sha384-…" crossorigin="anonymous"

Put it into a <script> or <link> tag so the browser only runs an embedded third-party resource if its content matches exactly. For a real file, use the File tab — the SRI line is produced there in the same way.

File hashing (File)

The File tab computes checksums for an entire file — handy for verifying a download against a published value or building the SRI value for a library.

Choosing algorithms

Below the drop area, Algorithms for files lists all 20 algorithms as toggle buttons ("each one costs time on big files"). Preselected are MD5, SHA-1, CRC-32, SHA-256, SHA-512, SHA3-256, and BLAKE3. The tool remembers your selection for your next visit. If nothing is selected, it reports "Select at least one algorithm."

The selection applies to the next hashing run: if you switch on another algorithm after hashing, drop the file again to get that value as well.

The switch Also compute HMACs with the key from the Text tab additionally computes HMACs with whatever key is in the HMAC key field of the Text tab (using its encoding). Without a key there, you simply get the plain hashes.

Choosing a file

Drag a file onto the drop area ("Drag & drop a file here") or click it to open the file dialog ("or click to choose — the file stays on your computer"). Hashing starts immediately — there's no separate start button. While it runs, the line above the table shows the file name, the size, and — if known — the MIME type.

Hashing

The tool reads the file in chunks (streaming) and feeds each chunk to all selected algorithms at once. There is no fixed size limit: the file is never loaded into memory in full, so the only constraint is computing time. During the run, the progress bar shows the percentage, the throughput (e.g. MB/s), and the estimated time remaining ("about N s left"). Cancel stops the run.

When it's done, the line above the table shows the file name, the size, and the duration ("hashed in X s"). The table is laid out just like in the Text tab: grouped, with a Copy button per row, in the format you picked under Output in the Text tab. Without HMAC, the SRI line appears below it — sha384-… if SHA-384 is selected, otherwise the stronger of the selected SHA-256 and SHA-512 values.

Verifying a checksum

Paste the checksum published by the vendor into the field "Paste the published checksum to verify the download…" — as hex, Base64, an SRI value, or a whole line from a .sha256 file. If it matches, the row turns green and "Match:" names the algorithm. If nothing matches, the message reads "No algorithm produces this hash — the file differs, or the algorithm is not selected." — either the file is a different one, or the right algorithm wasn't selected for the run.

The tech behind it

All computation runs in a Web Worker, outside the main thread — the page stays responsive even with large files.
The hash functions come from @noble/hashes (MIT); CRC-32 is implemented in the tool itself, and bcrypt comes from bcrypt.js (BSD-3-Clause).
Everything happens locally in the browser. The file is never uploaded.

Password hashing

The third tab creates and verifies password hashes — deliberately slow, salted algorithms for storing passwords. A notice at the top of the tab reminds you never to store passwords as plain MD5 or SHA-256, and points out that PHP's password_hash() / password_verify() understand the bcrypt strings ( $2y$ ) and Argon2id strings created here.

Create a hash

Pick the method under Algorithm; the matching parameters appear below it.

bcrypt (preselected):

Cost — the cost factor, 2ⁿ rounds; allowed values are 4 to 15, default 12.
Prefix — $2y$ (PHP) (default) or $2b$ (current standard). Both prefixes denote the same algorithm; $2y$ is the spelling PHP itself produces.
bcrypt only processes the first 72 bytes of a password. If yours is longer, the tool warns you: "bcrypt only uses the first 72 bytes of a password — the rest is ignored."

Argon2id (recommended):

Memory (KiB) — the field offers 1,024 to 262,144 KiB in steps of 1,024, default 19,456 (19 MiB).
Iterations — field range 1 to 10, default 2.
Parallelism — field range 1 to 4, default 1.
The upper bounds and the step are only presets of the input fields. Only the lower bounds are enforced (1,024 KiB, 1 iteration, parallelism 1); a larger value you type in by hand is computed as is.
The defaults match the OWASP minimum; PHP itself uses 64 MiB and 4 iterations by default, as the note below the fields points out.
The result is a string in PHC format, the same kind PHP produces with PASSWORD_ARGON2ID: $argon2id$v=19$m=…,t=…,p=…$salt$hash (16-byte random salt, 32-byte hash).

PBKDF2-HMAC-SHA256 (Django format):

Iterations — the field offers 1,000 to 5,000,000 in steps of 1,000, default 600,000 (according to the note, the OWASP recommendation for PBKDF2-HMAC-SHA256). Only the lower bound of 1,000 is enforced; higher values typed in by hand are computed exactly as entered.
The result follows Django's format: pbkdf2_sha256$<iterations>$<salt>$<base64 hash>.

Then enter the password in the Password field (the eye icon shows and hides it) and click Hash password. While it computes ("Hashing… (deliberately slow)"), Cancel aborts the run. Afterwards the hash appears in a field with a copy button, and the info line reports the duration: "Took X s here — a good cost makes one hash take ~0.2–1 s on your server. Every run uses a new random salt." So every click produces a different hash for the same password — that's by design.

Verify a password

On the right, paste a stored hash into Stored hash, enter the Password, and click Verify. The tool detects the format automatically:

bcrypt with $2a$ , $2b$ , or $2y$ ,
Argon2id in PHC format ($argon2id$v=19$…),
PBKDF2 in Django format (pbkdf2_sha256$…).

The result reads "The password matches this hash." or "The password does NOT match this hash." Other formats — Argon2i, Argon2d, or scrypt, for example — are rejected with an error message. Verifying takes as long as creating, because the tool recomputes the hash with the parameters stored in the string.

History and storage

The footer holds the switch Remember recent text inputs in this browser. It is off by default — hashed texts are often passwords, as the note next to it says.

Switch it on and the tool stores the content of the Input field in your browser's localStorage as soon as you leave the field (not on every keystroke). It keeps the last 10 entries, stripped of leading and trailing whitespace; entries shorter than two characters are dropped.
Once there are entries, a clock icon (Recent inputs) appears above the field and lists them. Clicking one puts the text back and recomputes. The input encoding is not saved with it.
Forget deletes all stored entries. Switching the history off only hides the list — nothing is deleted until you click Forget.
Passwords and keys are never stored, not even with the history on. Apart from that, the tool only remembers settings: the tab, the output format, and the algorithm selection for files.

Operational limits — in brief

Privacy: text, files, and passwords are processed in the browser only; the tool sends nothing to a server.
File size: no fixed limit (streaming); the only constraint is computing time, which grows with every selected algorithm.
Output: hex, HEX, Base64, or Base64URL.
Text computation: live as you type, always all 20 algorithms.
HMAC: for every algorithm except SHAKE128/256, BLAKE3, and CRC-32; in the File tab via a switch.
Password hashes: bcrypt (cost clamped to 4 to 15), Argon2id (field range up to 256 MiB, 10 iterations, parallelism 4; only the lower bounds are enforced), PBKDF2-HMAC-SHA256 (field range 1,000 to 5,000,000 iterations; only the lower bound is enforced); verification for bcrypt, Argon2id, and PBKDF2 in Django format.
History: opt-in only, at most 10 text inputs, never passwords or keys.

For the introduction and the audiences, see the overview page. Concrete workflows are in the examples, the security context in the tips & tricks. You can try everything directly in the tool.