HCODX / Hash Generator
100% browser-based · UTF-8 safe · Web Crypto API

Hash Generator — SHA-256, SHA-1 & MD5 Online

Compute cryptographic hashes for text and files in your browser. SHA family and HMAC use the native Web Crypto API; MD5 and CRC32 use compact, test-vector-verified inline implementations. Text is treated as UTF-8 by default.

MD5 and SHA-1 are cryptographically broken — fine for non-security checksums, unsafe for digital signatures or password storage. For passwords, use the PBKDF2 tab (or, on the server, bcrypt/Argon2).
Algorithms
Input
Plain text
Bytes the text is encoded into before hashing.
Results
Pick algorithms and an input, then click Compute hashes.
HMAC parameters
Native, via Web Crypto.
Result
Fill the form above, then click Generate HMAC.
PBKDF2 parameters
600 000 is the modern minimum for SHA-256 (OWASP).
A random 16-byte salt per user is the standard practice.
Derived key
Fill the password and salt above, then click Derive key.
Verify a hash
Hex or Base64 — case-insensitive, whitespace ignored.
Result
Awaiting input
Fill the form and click Verify.
Example

Test vectors at a glance

Same input, three algorithms, different fingerprints — and a tiny change in input cascades through every byte.

Input
The quick brown fox jumps over the lazy dog
Hashes (hex)
MD5      9e107d9d372bb6826bd81d3542a419d6
SHA-1    2fd4e1c67a2d28fced849ee1bb76e7391b93eb12
SHA-256  d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592
SHA-512  07e547d9586f6a73f73fbac0435ed76951218fb7d0c8d788a309d785436bbb64
         2e93a252a954f23912547d1e8a3b5ed6e1bfd7097821233fa0538f3db854fee6
Use cases

What you'll actually use this for

Hashes show up in nearly every corner of software engineering.

File integrity

Verify a downloaded ISO, archive, or release against a published SHA-256 checksum to catch tampering or transfer corruption.

API request signing

Generate HMAC-SHA-256 signatures for webhook payloads, S3-style request signatures, or tamper-evident cookie values.

Content addressing

Use SHA-256 digests as stable identifiers — Git's content store, Docker layer IDs, and IPFS all do the same thing.

Password-derived keys

Use PBKDF2 to stretch a password into a strong symmetric key for client-side encryption (LastPass-style flows).

Forensics & dedup

Spot duplicate files, identify malware samples, or correlate ticket attachments by their cryptographic digest.

CRC32 quick checks

Fast 32-bit checksum for non-cryptographic uses — corruption detection in network frames, ZIP files, and embedded systems.

Step by step

How to use the hash generator

Pick a tab, enter your input, click compute.

1

Pick the right tab

Use Hash for plain digests, HMAC when you need a keyed signature, PBKDF2 for password-derived keys, and Verify to compare a file or text against a published hash.

2

Choose algorithms

The Hash tab supports several at once — useful for cross-checking. SHA-256 is the right modern default; MD5 and SHA-1 are kept for compatibility with older systems.

3

Pick the right charset

UTF-8 by default. Switch to ASCII or Latin-1 only when matching a legacy system that hashes single-byte text. Out-of-range characters are rejected with a clear error rather than silently truncated.

4

Compute and copy

Each result row has a copy button. The "Copy all" toolbar action emits a labelled list ready to paste into a release-notes table or a security review.

FAQ

Frequently asked questions

Everything worth knowing about hashing.

A hash function takes an input of arbitrary size and produces a fixed-size output (the digest). Cryptographic hashes are:

  • Deterministic — same input, same digest, every time.
  • One-way — given a digest, you can't recover the input.
  • Avalanche-prone — a one-bit change in input flips about half the bits of the digest.
  • Collision-resistant — finding two different inputs with the same digest should be infeasible.

They underpin file integrity, digital signatures, password storage (with extra ingredients), HMAC, and content-addressable storage.

  • General integrity: SHA-256 is the right default.
  • Password storage: never a plain hash. Use bcrypt, scrypt, Argon2, or PBKDF2 with a high iteration count.
  • Message authentication: HMAC-SHA-256 with a strong shared secret.
  • Non-security checksums: CRC32 is plenty.
  • Legacy compatibility: MD5 and SHA-1 are still useful for matching pre-existing checksums, but unsafe for any new security-sensitive use.

Almost always a text-encoding mismatch. Hashes operate on bytes, not characters. Hashing the string "é" as UTF-8 (two bytes: C3 A9) produces a different digest than as Latin-1 (one byte: E9).

This tool uses UTF-8 by default and exposes ASCII / Latin-1 modes for legacy compatibility. Out-of-range characters are rejected with an explicit error rather than silently truncated. Tools that quietly use charCodeAt() & 0xFF will produce different results — and they're usually the ones that are wrong.

A plain hash gives integrity — anyone with the input can recompute the digest. HMAC layers a shared secret on top of a hash, so only someone with the key can produce a valid digest for a message.

Use HMAC when you need authenticity, not just integrity:

  • Webhook signatures (Stripe, GitHub, etc.)
  • API request signing (AWS Signature v4)
  • Tamper-evident cookies and session tokens

Both have demonstrated practical collision attacks — researchers can produce two different inputs that share a digest:

  • MD5 collisions were demonstrated in 2004; weaponized for a rogue SSL certificate by 2008.
  • SHA-1 collisions were demonstrated in 2017 (the SHAttered attack).

They're still adequate for casual integrity checks — matching a download to a published checksum where attackers can't substitute both ends. They're unsafe for digital signatures, certificates, or anywhere an adversary controls the input.

No. Everything runs in your browser. The SHA family, HMAC, and PBKDF2 use the native Web Crypto API; MD5 and CRC32 use compact inline implementations validated against published test vectors. Files are read into memory locally and never uploaded.

PBKDF2 (Password-Based Key Derivation Function 2) deliberately slows down hashing by iterating an HMAC many thousands of times, making brute-force expensive. It's the standard tool for stretching a password into a strong symmetric key for client-side encryption, or for storing a password verifier.

Modern guidance (OWASP, 2024):

  • ≥ 600 000 iterations of HMAC-SHA-256
  • ≥ 210 000 iterations of HMAC-SHA-512
  • 16-byte random salt per password

For greenfield projects, prefer Argon2 or bcrypt — both are designed specifically for password storage and resist GPU brute-forcing better than PBKDF2.

Yes, on a desktop browser with enough RAM. The file is read into memory once, then handed to the Web Crypto API (for SHA family) or the inline MD5/CRC32 routine. Practical limits depend on your machine — most modern laptops handle multi-gigabyte files comfortably; mobile devices may run out of memory earlier.

About

About hash functions

A hash function is a deterministic mapping from arbitrary-length input to fixed-length output. Cryptographic hash functions add three security properties on top: pre-image resistance (you can't recover the input from the digest), second pre-image resistance (you can't find a second input with the same digest as a given one), and collision resistance (you can't find any two distinct inputs with the same digest).

Algorithms in this tool

  • MD5 — 128-bit digest. Standardized in RFC 1321 (1992). Broken since 2004. Still useful for non-security checksums.
  • SHA-1 — 160-bit digest. Broken since 2017. Avoid for new security-sensitive uses.
  • SHA-2 family (SHA-256, SHA-384, SHA-512) — current cryptographic workhorse. No known attacks against the full hash. SHA-256 is the most common; SHA-512 is faster on 64-bit CPUs and gives a larger digest.
  • CRC32 — 32-bit checksum. Not cryptographic. Detects accidental corruption in transmitted data.
  • HMAC — keyed authentication built on top of any hash. Same hash names apply (HMAC-SHA-256, etc.).
  • PBKDF2 — password-based key derivation, deliberately slow.

Output formats

The same digest can be displayed several ways. Hexadecimal (the default) is human-readable and ubiquitous. Base64 is more compact (~33% shorter than hex) and often preferred for HTTP headers like Authorization or Digest. Bytes are bytes — the format is a presentation choice, not a different value.

What hashing isn't

  • Encryption. Hashing is one-way. If you need to recover the original later, use a cipher.
  • A perfect identifier. Two distinct inputs can share a digest — collision resistance just makes it astronomically unlikely with modern hashes.
  • Sufficient on its own for password storage. Plain SHA-256 of a password is faster to brute-force than you'd hope. Use a password-specific KDF (bcrypt, Argon2, PBKDF2 with high iteration counts).

Practical tips

  • When publishing a release, post the SHA-256 alongside the download — and sign that file in turn so attackers can't tamper with both.
  • For HMAC, the secret must be high-entropy (a random 256-bit value, not "password").
  • When verifying, paste the published hash and let the tool tell you match/mismatch — comparing long hex strings by eye is error-prone.