SHA Hash Generator for Text and Files

How to calculate a SHA digest

Choose text or file input, select an algorithm and output encoding, then generate. Text is encoded as UTF-8 before hashing. File mode reads the exact local file bytes into browser memory and sends them directly to SubtleCrypto.digest.

1. Select Text for a typed string or File for local bytes. The tool never converts file content to text before hashing.
2. Choose SHA-256 for a broadly supported modern default, or SHA-384/SHA-512 when a protocol explicitly requires them.
3. Choose hexadecimal for common checksum displays or Base64 for compact transport in systems that expect it.
4. Generate and compare the complete digest with a trusted source. A matching digest supports integrity, not authorship, unless the expected value was authenticated separately.

Examples and expected behavior

Hash functions and deterministic output

A cryptographic hash function maps any length of input to a fixed-length digest. The same byte sequence always produces the same result, while a small input change should produce a very different digest. Hashing is one-way in the practical sense: the digest does not contain a reversible copy of the original data.

Determinism makes hashes useful for integrity checks, content addressing, cache keys and reproducible build records. It also means hashing a low-entropy secret does not hide it from guessing attacks. Attackers can hash candidate passwords or identifiers and compare results. Password storage requires a dedicated slow, salted password-hashing function rather than a general SHA digest.

• SHA-256 output is 32 bytes.
• Hex doubles the byte count into two characters per byte.
• Base64 is shorter text but represents the same digest bytes.

Algorithm selection and SHA-1 warning

SHA-256, SHA-384 and SHA-512 are members of the SHA-2 family and remain standard choices when used according to a protocol. Select the exact algorithm required by the checksum, API or file publisher; digests from different algorithms are not interchangeable. A longer digest is not automatically better if the surrounding protocol is implemented incorrectly.

SHA-1 is included only because older systems and published checksums may still require it. Practical collision attacks mean SHA-1 should not be chosen for new collision-resistant signatures, certificates, software distribution or adversarial integrity decisions. It can still identify accidental changes in a legacy workflow, but migrate to SHA-256 or a stronger approved construction when security matters.

• Do not compare a SHA-1 checksum as proof against a capable attacker.
• Follow the algorithm named by the source instead of guessing from digest length alone.
• HMAC is different from a plain hash and requires a secret key.

Text encoding and exact file bytes

Text input is converted to UTF-8 with TextEncoder. Visually similar strings can have different bytes because of Unicode normalization, invisible characters, line endings or trailing spaces. The tool does not normalize text. If another system hashes UTF-16, a legacy code page or normalized Unicode, its digest will differ even when the screen appears similar.

File mode hashes the bytes returned by File.arrayBuffer. It does not inspect file names, MIME types or modification times unless those values are embedded inside the file content itself. Re-saving an image or document can change internal metadata and therefore change the digest. For cross-platform text files, CRLF versus LF is a frequent source of mismatches.

• Copy text exactly, including final newlines.
• Compare file size when diagnosing a checksum mismatch.
• Document encoding and normalization rules in any protocol that hashes human text.

Integrity checks and trust model

A matching digest shows that two byte sequences are extremely likely to be identical for the chosen algorithm. It does not prove who created the bytes or whether the expected digest is trustworthy. If an attacker can replace both a download and the checksum displayed beside it, a plain hash comparison provides no authenticity.

Obtain expected checksums through an authenticated channel, a signed release manifest, package-manager metadata or another trusted mechanism. For messages shared between parties with a secret, use HMAC. For public software provenance, use digital signatures and a verified public key. Hashes are building blocks; the surrounding trust path determines the security claim.

• Compare the entire digest, not a short prefix.
• Use constant-time comparison in security-sensitive application code.
• Record the algorithm together with the digest.

Common uses and operational workflow

Typical uses include verifying downloaded files, checking whether two exports differ, recording build artifacts, generating cache keys and confirming test vectors. File hashing in this page is convenient for local inspection because the bytes do not need to be uploaded. Text hashing is useful when debugging API canonicalization or encoding rules.

For reproducible results, save the original input, algorithm, output encoding and any text-normalization rule. When a digest differs, compare byte length, line endings, Unicode normalization, compression and embedded metadata before suspecting the hash function. Do not paste confidential data into issue trackers merely to explain a mismatch; share the digest and non-sensitive reproduction details.

• Verify a release checksum from a trusted publisher.
• Compare two local files without uploading them.
• Check known cryptographic vectors during implementation.
• Diagnose UTF-8 versus other text-encoding differences.

Browser limits, errors and non-goals

Web Crypto is required. If SubtleCrypto is unavailable, the operation fails rather than using an unreviewed JavaScript hash implementation. File mode currently reads the selected file into memory as one ArrayBuffer, so very large files can consume substantial memory and may pause the page. A streaming native tool is preferable for multi-gigabyte files.

This page does not crack hashes, identify an unknown algorithm with certainty, encrypt data, sign messages or store password hashes. Digest length can suggest an algorithm but is not proof. It also does not upload a file to compare against malware databases or reputation services. The output is only the selected algorithm’s digest of the supplied bytes.

• No file is selected until you choose one in the browser control.
• Clearing the form drops this page’s references but cannot clear operating-system caches.
• Use dedicated password hashing such as Argon2, scrypt or bcrypt for credentials.

How this differs from HMAC and UUID

A plain hash has no secret key, so anyone with the data can reproduce it. HMAC combines a secret with the message and is designed to verify authenticity and integrity between parties that share that secret. A UUID v4 is random and identifies an object; it is not derived from content and cannot verify that content stayed unchanged.

Use a hash for checksums and content identity, HMAC for keyed message authentication, a digital signature for public-key authenticity and a UUID for random identifiers. These outputs may all look like long strings, but substituting one for another removes important security properties.