Hash Generator

A digest is a fingerprint of bytes

A cryptographic hash function accepts bytes of any practical length and deterministically returns a fixed-length digest. Change one input bit and a well-designed function produces an unrelated-looking result. The same bytes and algorithm always produce the same digest. There is no key, no randomness, and no decryption operation.

This online SHA-256 hash generator computes MD5, SHA-1, SHA-256, and SHA-512 for UTF-8 text. It can render each digest as lowercase hexadecimal, uppercase hexadecimal, or Base64. Those formats encode the same result bytes; selecting Base64 does not hash again and does not add encryption. The page recomputes while you type, includes the empty-string vectors, provides a copy action per algorithm, and can clear the input.

The distinction between text and bytes is crucial. The component uses TextEncoder, so hello becomes the five UTF-8 bytes 68 65 6c 6c 6f. A file hash utility reads the file’s raw bytes instead. Pasting binary-looking content, a Base64 string, or hex digits here hashes those visible characters, not the decoded binary value.

Compare the four outputs

MD5 returns 128 bits: 32 hexadecimal characters or 24 Base64 characters with padding. Practical collision attacks make it unsuitable for signatures, certificates, adversarial integrity, or any design that relies on collision resistance. It remains common in legacy file checksums where accidental corruption, not a malicious replacement, is the concern.

SHA-1 returns 160 bits: 40 hex characters. Chosen-prefix and other collision attacks have retired it from modern security protocols. It can still appear in Git object identifiers and old integration specifications, but a new protocol should not select it.

SHA-256 is a SHA-2 member with a 256-bit output, represented by 64 hex characters or 44 padded Base64 characters. It is the usual general-purpose choice for content-addressing, release checksums, cache keys, and digest inputs in modern protocols.

SHA-512 is another SHA-2 member with a 512-bit output, producing 128 hex characters or 88 padded Base64 characters. A longer digest is not automatically “more encrypted”; neither function encrypts. Protocol compatibility, security requirements, platform performance, and specified truncation determine the selection.

Reproduce a known vector

Enter exactly hello, with no quotes or newline, and choose lowercase hexadecimal. SHA-256 should be:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Now append one space. The digest changes completely because the input gained byte 20. Clearing the field computes the SHA-256 digest of zero bytes:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

An empty digest is not missing data; it is the defined result for an empty message. This is a useful test for library initialization and encoding agreement.

Switching Hexadecimal (lowercase) to Hexadecimal (uppercase) changes only letters a through f. Comparisons that parse hex should normally be case-insensitive, while brittle string-based protocols may require a particular case. Base64 represents the same digest in a smaller printable form. Standard Base64 uses +, /, and =; Base64url uses -, _, and often omits padding, so do not interchange them without the protocol’s conversion rules.

Integrity workflow for releases and APIs

For a downloadable artifact, the publisher computes SHA-256 over the exact file bytes and publishes the expected digest through an authenticated channel. The recipient computes it independently and compares. A match gives strong evidence that the bytes match the bytes originally hashed. It does not identify the publisher by itself: an attacker who can replace both file and checksum can calculate a matching checksum. Signed release metadata, TLS, package-manager signatures, or a separately authenticated digest provides provenance.

This text tool is suitable for checking canonical strings used in development. Use shasum -a 256 file.tar.gz, OpenSSL, or a trusted language library for files; do not paste a file’s textual rendering. In a test suite, include official vectors, empty input, non-ASCII input such as café, embedded NUL bytes when the API supports bytes, and multi-megabyte streaming input. Confirm both digest bytes and formatting.

API protocols often hash a canonical request. Every newline, header case rule, percent encoding, and body byte must match the specification. Log an escaped canonical representation in a safe test environment when signatures disagree. Do not “fix” a mismatch by uppercasing the digest or trimming the message unless the protocol explicitly says so.

Hashing, HMAC, and encryption are different tools

An unkeyed digest detects accidental change only when the expected value is trusted. If an attacker can edit the message and digest, use a message authentication code such as HMAC-SHA-256. HMAC combines a secret key with a hash using a defined construction; it is not SHA256(secret + message). A digital signature instead uses a private key and allows public verification.

Encryption protects confidentiality and is reversible with an authorized key. Hashing is designed to be one-way, but “one-way” does not make low-entropy input safe. An attacker can hash guesses and compare them. That is why a fast SHA-256 hash is wrong for password storage even though SHA-256 itself remains cryptographically sound.

Passwords require a unique salt and a deliberately expensive password-hashing function such as Argon2id, scrypt, bcrypt, or PBKDF2. Salting SHA-256 manually does not supply memory hardness or sufficient work. Conversely, bcrypt is inappropriate as a general file checksum because it is randomized, slow, and has password-specific input behavior.

Canonicalization traps

Most apparent hash failures are input failures. \n may mean two visible characters or one line-feed byte. Windows CRLF (0d 0a) and Unix LF (0a) produce different results. Unicode é can be encoded as one code point or an e plus combining accent; visually equal strings need not have equal UTF-8 bytes. JSON whitespace and property order matter unless a canonical JSON scheme is used.

Never normalize silently on only one side. Define whether input is raw bytes or text, the character encoding, newline policy, Unicode normalization form if any, and output encoding. Preserve leading and trailing whitespace. When comparing secret-derived tags, decode to bytes and use a constant-time comparison rather than ordinary string equality to reduce timing leakage.

Length also matters operationally. This component holds text and four outputs in browser memory and is not a streaming file hasher. Very large content can make the UI slow. Browser clipboard contents may be observed by extensions or clipboard history, so do not paste secrets merely to calculate a digest.

When a protocol truncates a digest, preserve the specified bytes in the specified order. Taking the first 16 raw bytes of SHA-256 is not the same as taking 16 hexadecimal characters, which represent only eight bytes. Truncation reduces collision and preimage margins, so it belongs in a reviewed protocol rather than an ad hoc database formatting decision.

Common mistakes to catch in review

• Calling a digest “encrypted” and expecting to recover the input.
• Using MD5 or SHA-1 where a malicious party can choose colliding inputs.
• Comparing a hash of UTF-8 text with a hash of decoded hex or Base64 bytes.
• Treating an unkeyed SHA-256 checksum as proof of sender authenticity.
• Storing user passwords as plain SHA-256, even with a global salt.
• Truncating a digest without analyzing collision and forgery requirements.
• Committing a checksum beside an artifact while leaving both replaceable by the same attacker.

FAQ

Why does my SHA-256 hash not match another tool?

Check hidden whitespace, newline style, UTF-8 versus another encoding, Unicode normalization, and whether the other tool hashes decoded bytes. Then verify both sides use SHA-256 rather than HMAC-SHA-256 or double hashing.

Can a hash be reversed?

There is no general inverse operation. Attackers recover weak inputs by guessing candidates and comparing digests, not by decrypting the hash.

Is hexadecimal more secure than Base64?

No. They are reversible encodings of identical digest bytes. Hex is easier to inspect; Base64 is shorter.

Should I use SHA-512 instead of SHA-256?

Use the algorithm required by your protocol. Both remain accepted general-purpose hash functions, but output size and performance differ. Do not migrate by changing one side of an integration.

Can this hash generator verify a downloaded file?

Not directly. It hashes entered UTF-8 text. Use a file-aware hashing command or application that reads the exact file bytes.