Skip to content
CalcLab

Hash Generator

Compute a SHA-256, CRC-32, or FNV-1a hash of text.
SHA-256
No data
No results yet — Enter values and run the tool to see results.

What is this calculator?

Computes a hash of text using SHA-256, CRC-32, or FNV-1a. The three serve different purposes: SHA-256 is a cryptographic digest, while CRC-32 and FNV-1a are fast non-cryptographic checksums for detecting accidental change or distributing keys.

Use it when:

  • You need to verify that a piece of text matches a published SHA-256 digest.
  • You want a short checksum to detect accidental corruption.
  • You need a fast, well-distributed hash for a lookup table.

Intended for: Developers verifying integrity, building caches, or comparing content fingerprints.

How is this calculated?

  1. The text is first converted to UTF-8 bytes, so the digest depends on the exact characters, not on any display encoding.
  2. SHA-256 processes those bytes in 512-bit blocks through 64 rounds of compression, producing a fixed 256-bit (64 hex character) digest. It is designed so that finding two inputs with the same digest is computationally infeasible.
  3. CRC-32 treats the input as a polynomial over a finite field and computes its remainder, producing a 32-bit value that reliably detects burst errors — its actual design purpose.
  4. FNV-1a repeatedly multiplies a running value by a prime and mixes in each byte, producing a 32-bit value that is fast and well distributed for hash tables.
  5. Every algorithm is deterministic: the same input always produces the same output, and a single changed character changes the result completely.

Example

Hashing the text `hello` with SHA-256.

Result: `2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824` — 64 hexadecimal characters, and changing `hello` to `Hello` produces an entirely different digest.

Frequently asked questions

Can a hash be reversed to recover the original text?

Not by design. Hashing is one-way. However, short or common inputs can be found by brute force or lookup tables, which is why passwords must be hashed with a slow, salted algorithm rather than a plain digest.

Should I use this to hash passwords?

No. Password storage requires a deliberately slow, salted algorithm such as bcrypt, scrypt, or Argon2. A fast digest like SHA-256 is exactly the wrong tool for that job.

When would I choose CRC-32 or FNV-1a?

When you need speed and only care about detecting accidental change or spreading keys across buckets. Neither offers any security: both are trivial to collide deliberately.

Why does a whitespace change alter the whole hash?

Because the digest depends on every byte. This avalanche property is intentional — it is what makes a hash useful for detecting any modification, however small.

Assumptions

What this calculator takes as given:

  • The transformation is performed in your browser; the text you paste is not uploaded or stored.
  • Input is treated as UTF-8 text.
  • The digest is computed over the UTF-8 bytes of the exact text entered, including trailing whitespace and line endings.

Limitations

What this calculator cannot know or does not model:

  • Only text is hashed; file hashing is not supported.
  • CRC-32 and FNV-1a offer no security properties and must not be used where collision resistance matters.
  • No salting, key derivation, or HMAC construction is provided.

References

Related tools