Hashing Guide

Hashing Guide explains how hash functions turn input data into fixed-size fingerprints, why tiny input changes produce different digests, which algorithms are appropriate for modern integrity checks, and why password hashing requires a different approach. This practical guide covers SHA-256, SHA-512, SHA-1, MD5, HMAC, checksums, salts, collisions, file verification, password storage, and common implementation mistakes.

Tip: Choose a hash algorithm for the actual job. SHA-256 is suitable for many integrity workflows, HMAC adds authentication with a secret key, and dedicated password-hashing algorithms are designed for stored passwords.

Hashing Guide: what is hashing?

A hash function accepts data of almost any length and produces a digest of a fixed length. The same bytes processed by the same algorithm produce the same digest. Change even one byte and a well-designed cryptographic hash should produce a substantially different result.

Hashing is one-way in normal use. A digest is not an encrypted copy of the original message and there is no decryption key that restores the input. This makes hashing useful for integrity checks, content identifiers, digital-signature workflows, cache keys, deduplication, and many security protocols.

For example, SHA-256 produces a 256-bit digest, commonly displayed as 64 hexadecimal characters. The output length stays the same whether the input is one character or a large file.

Input:  hello
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Hashing Guide to core cryptographic hash properties

Deterministic output

The same exact input bytes always produce the same digest with the same algorithm. This is why hashes are useful for repeatable verification.

Fixed-size digest

The digest length is determined by the algorithm rather than the input length. SHA-256 always produces 256 bits; SHA-512 always produces 512 bits.

Avalanche effect

A small change in the input should change many output bits. This prevents similar messages from producing visibly similar digests and makes accidental changes easy to detect.

Preimage resistance

Given a secure digest, finding an input that produces it should be computationally impractical. This property is important, but it does not make fast general-purpose hashes suitable for passwords.

Collision resistance

A collision occurs when two different inputs produce the same digest. Because the output space is finite, collisions must theoretically exist. A cryptographic algorithm is designed to make finding a useful collision infeasible.

Hashing Guide to common algorithms

Algorithm	Typical digest	Recommended role
SHA-256	256 bits / 64 hex chars	Modern integrity checks and general cryptographic hashing
SHA-512	512 bits / 128 hex chars	Modern integrity checks when a larger digest is useful
SHA-1	160 bits / 40 hex chars	Legacy compatibility only; not collision-resistant for security use
MD5	128 bits / 32 hex chars	Legacy/non-adversarial checks only; not secure against collisions
CRC32	32 bits / 8 hex chars	Accidental error detection, not cryptographic security

Use the Hash Generator when you want to compare multiple digest algorithms from the same input. For a focused workflow, open the SHA-256 Generator.

Hashing Guide to SHA-256 and SHA-512

SHA-256 and SHA-512 belong to the SHA-2 family. They are widely supported in programming languages, command-line utilities, APIs, package systems, signing workflows, and file-distribution pipelines. For new general-purpose cryptographic integrity work, SHA-2 is a sensible baseline when a protocol does not require another algorithm.

The larger SHA-512 digest is not automatically necessary for every application. Compatibility, protocol requirements, implementation support, and the surrounding security design matter more than choosing the longest visible output.

The NIST Hash Functions project documents approved hash standards and related guidance.

Hashing Guide: why MD5 and SHA-1 are legacy

MD5 and SHA-1 remain common in old systems, download manifests, database exports, source-control history, and compatibility workflows. Their continued presence does not make them appropriate for new security-sensitive collision-resistance requirements.

Researchers have demonstrated practical collision attacks against both families. A deliberately crafted pair of different files can therefore undermine a workflow that assumes matching MD5 or SHA-1 values prove authenticity. Use MD5 Generator or SHA-1 Generator only when you must reproduce or inspect a legacy value, not as a new security design.

Warning: A matching legacy checksum can confirm that two byte sequences produced the same digest, but it should not be treated as strong proof that an attacker could not have manipulated the content.

Hashing Guide to hashing versus encryption and encoding

Hashing is designed as a one-way transformation that produces a digest. Encryption is reversible with the appropriate key and is used to protect confidentiality. Encoding, such as Base64 or URL encoding, changes representation so data can be transported or embedded safely; it provides no secrecy.

Confusing these operations leads to weak systems. A Base64 string is not encrypted, and a SHA-256 digest cannot simply be decrypted. Select the primitive according to whether you need integrity, authentication, confidentiality, or transport-safe representation.

Hashing Guide to hash functions versus checksums

Checksums such as CRC32 are optimized for detecting accidental corruption. Cryptographic hashes are designed to resist deliberate attempts to create the same digest. Both can detect ordinary changes, but their threat models are different.

Use the Checksum Calculator when a file format, protocol, or legacy system explicitly requires a checksum. Use SHA-256 or another approved cryptographic hash when adversarial manipulation matters.

Hashing Guide to hashing versus HMAC

A plain hash can tell you whether content changed compared with a trusted digest, but anyone who can alter both the message and its published hash can calculate a new matching value. HMAC combines a cryptographic hash with a secret key so only parties that know the key can create the expected authentication code.

message + secret key → HMAC-SHA-256 → authentication code

HMAC is commonly used for webhook signatures, API request authentication, signed callbacks, and message integrity between trusted systems. Use the HMAC Generator to reproduce test vectors and inspect how the message, secret, and selected algorithm affect the result.

Why passwords need dedicated password hashing

Fast hashes such as SHA-256 are intentionally efficient. That is useful for files and messages but dangerous for stored passwords because an attacker with a stolen password database can test guesses extremely quickly.

Password storage should use a dedicated password-hashing or key-derivation algorithm with a unique salt and an adjustable work factor. Depending on the platform and current security policy, common choices include Argon2id, scrypt, bcrypt, or PBKDF2. The OWASP Password Storage Cheat Sheet provides current implementation guidance.

Trexmi includes a BCrypt Hash Generator for controlled testing and compatibility work. Production applications should rely on their framework's maintained password APIs rather than manually assembling password hashes.

What is a salt?

A salt is a unique random value combined with a password before password hashing. It prevents identical passwords from automatically producing identical stored hashes and makes precomputed lookup tables much less useful. A salt does not need to be secret; it is normally stored alongside the resulting password hash.

Do not confuse a salt with an HMAC secret or encryption key. Their purposes and security requirements are different. Modern password APIs usually generate, encode, and store salts automatically.

Hashing Guide to verifying downloaded files

1. Obtain the expected digest from a trusted source.
2. Confirm which algorithm was used, such as SHA-256.
3. Hash the downloaded file as raw bytes.
4. Compare the complete digest, not only the first or last characters.
5. If the values differ, treat the file as changed or corrupted and investigate before using it.

A successful comparison proves that your file matches the bytes represented by the trusted digest. It does not establish who originally created the file unless the digest itself is authenticated through a trusted signature or secure publication channel.

Text encoding, whitespace, and byte-level differences

Hash functions process bytes, not visual meaning. The strings Hello and hello are different. So are a file with a trailing newline and the same visible text without that newline. UTF-8 and UTF-16 representations of the same characters also contain different bytes.

"hello" ≠ "hellon"
"A"     ≠ "a"

When two systems produce different digests, inspect character encoding, newline style, Unicode normalization, byte-order marks, whitespace, serialization rules, and whether one side hashes raw bytes while the other hashes a hexadecimal or Base64 representation.

Practical hashing examples

JavaScript with Web Crypto

const bytes = new TextEncoder().encode("hello");
const digest = await crypto.subtle.digest("SHA-256", bytes);
const hex = [...new Uint8Array(digest)]
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

PHP

$digest = hash("sha256", "hello");

Python

import hashlib

digest = hashlib.sha256(b"hello").hexdigest()

These examples all hash the same UTF-8/ASCII byte sequence and should therefore produce the same SHA-256 hexadecimal digest.

Common hashing mistakes

• Hashing visible text instead of the required raw bytes. File hashes must normally process the file bytes directly.
• Comparing different output formats. Hexadecimal, Base64, uppercase hex, and raw binary can represent the same digest differently.
• Using MD5 or SHA-1 for new security-sensitive collision resistance. Keep them for compatibility only.
• Using plain SHA-256 for passwords. Use a dedicated password-hashing API.
• Assuming a hash proves authorship. Authentication requires a trusted signature, MAC, or other authenticated mechanism.
• Ignoring whitespace and encoding. One invisible byte changes the digest.
• Truncating the comparison unnecessarily. Compare the complete expected digest unless a protocol explicitly defines truncation.

A reliable Hashing Guide workflow

1. Define whether you need error detection, cryptographic integrity, authentication, password storage, or confidentiality.
2. Select the algorithm required by that use case or protocol.
3. Preserve the exact source bytes and character encoding.
4. Generate the digest with a maintained implementation.
5. Record the output format: raw bytes, hexadecimal, or Base64.
6. Compare complete values using the correct rules.
7. Test known vectors before integrating two different systems.
8. Document legacy algorithms so they are not reused accidentally for new security work.

For quick testing, start with the Hash Generator, verify a modern digest with the SHA-256 Generator, use HMAC Generator when a shared secret is part of the protocol, and use Checksum Calculator for non-cryptographic checksum formats.

Hashing Guide summary

A dependable hashing workflow begins with the correct threat model. Use modern cryptographic hashes such as SHA-256 for integrity, HMAC when integrity must be authenticated with a shared secret, dedicated password-hashing APIs for stored passwords, and checksums such as CRC32 only for accidental-error detection. Always hash the intended bytes, preserve encoding and whitespace, compare the complete digest, and treat MD5 and SHA-1 as legacy compatibility algorithms rather than new security choices.