🔐 SHA-1 Hash Generator - Generate SHA-1 checksums

📝 Input Method

🔐 Hash Algorithms

🎨 Output Format

📝 Input Text

📄 File Selection

📄

Drop file here! Drag and drop a file here

or

Select a file to generate hashes

Selected Files ({{ selectedFiles.length }})
Total Files: {{ fileCount }} Total Size: {{ formatFileSize(totalSize) }}

⏳ Processing...

Generating hashes...

📊 Hash Results

📊 Hash Results

Select algorithms and enter text or upload a file to generate hashes...

⚠️

ℹ️ About Hash Generation

A hash function maps text or file bytes to a fixed-length digest. The same input always produces the same digest. For the cryptographic functions here (MD5, SHA-1, SHA-256, SHA-512) a single changed byte produces an unrelated-looking output; the CRC32 and Adler-32 checksums make no such promise, and neighbouring inputs give neighbouring values (Adler-32 of a is 00620062, of b is 00630063). Hashes are not encryption: there is no key, and the digest cannot be turned back into the data.

This tool computes MD5, SHA-1, SHA-256, SHA-512, CRC32 and Adler-32 for typed text or one file, recalculating as you type and showing each selected digest as lowercase or uppercase hex. Use it to check a download against a publisher's SHA-256 checksum, make reproducible checksums for build artifacts, or produce legacy MD5 and SHA-1 values for an older system.

Algorithm strength guide:

  • SHA-256 and SHA-512 (strong, recommended): the SHA-2 functions specified by NIST FIPS 180-4. Use these for new integrity checks and protocol work.
  • MD5 (broken, legacy only): 128-bit digest from RFC 1321; RFC 6151 warns against it wherever collision resistance matters.
  • SHA-1 (broken, legacy only): 160-bit digest; keep it only for old checksum formats, because NIST recommends migrating from SHA-1 to SHA-2 or SHA-3.
  • CRC32 and Adler-32 (not cryptographic): fast 32-bit error detection for archive formats and accidental corruption. CRC32 is the gzip checksum in RFC 1952; Adler-32 is the zlib checksum in RFC 1950.

Supported inputs

  • Text: any string typed or pasted into the Input Text box, hashed as UTF-8 bytes, so accented and non-Latin characters count as two or more bytes. Results recompute on every keystroke.
  • File: one file per run, via Browse Files or the drop zone; a new choice replaces it. It is read into browser memory and hashed as raw bytes, never uploaded.
  • Algorithms: any combination of the six checkboxes, with ids md5, sha1, sha256, sha512, crc32 and adler32. MD5 and SHA-256 start selected.
  • Output format: lowercase hex (the default) or uppercase HEX; switching re-renders every selected digest at once.
  • API: POST /api/tools/crypto/hash with text (an empty string is allowed), algorithms (an array of the ids above, or an object map of id to boolean; omit it to get md5 and sha256) and outputFormat (hex or HEX; anything else becomes hex). Unknown ids are dropped, and the API takes text only, not files.

Output

Each selected algorithm gets its own labelled panel with a Copy button. Digests are fixed-width hex: 32 characters for MD5, 40 for SHA-1, 64 for SHA-256, 128 for SHA-512, and 8 zero-padded characters for CRC32 and Adler-32. When you publish a checksum, put the algorithm name next to the digest, for example SHA-256: ..., so readers know exactly what to compare. The API returns hashes (all six keys, empty for algorithms you did not request), algorithms (the ids computed, in your order for an array, or in the fixed order md5, sha1, sha256, sha512, crc32, adler32 for a map), outputFormat and inputLength (the UTF-8 byte count of text).

Example

The text abc (3 bytes, no trailing newline) with every algorithm selected and lowercase output produces:

  • MD5: 900150983cd24fb0d6963f7d28e17f72
  • SHA-1: a9993e364706816aba3e25717850c26c9cd0d89d
  • SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
  • SHA-512: ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f
  • CRC32: 352441c2
  • Adler-32: 024d0127

The MD5 value is the RFC 1321 appendix A.5 test vector, and the SHA values match NIST's published SHA example values. Change one byte, space or line ending and every digest changes, so compare the exact bytes you plan to verify.

Limitations

  • Only these six algorithms are available: no SHA-224, SHA-384, SHA-3, BLAKE, RIPEMD or Whirlpool. Use the SHA-3 Generator for Keccak-based digests and the Checksum Calculator for CRC-16, Fletcher, FNV and other non-cryptographic checksums.
  • Text is always hashed as UTF-8, with no option to read a hex or Base64 string as bytes or to pick another encoding. Output is hex only, with no Base64 rendering, no salt and no key; for a keyed digest use the HMAC Generator.
  • Files are read whole into browser memory, with no chunked streaming, so multi-gigabyte files can be slow or exceed what the browser allows. One file is hashed at a time; the File Hash Generator is the file-only variant.
  • There is no compare field: copy the digest and check it against the published value yourself. A matching hash shows that data is unchanged, not who produced it.
  • The page clears its results for empty or whitespace-only text. The API hashes exactly the bytes it receives, so an empty string returns each algorithm's empty-input digest (MD5 d41d8cd98f00b204e9800998ecf8427e), and three spaces are hashed as three space bytes.

Browser or server processing

Typed text is hashed in your browser by the compiled logic module (hash-generator.logic.js); file hashing also runs in the browser, with the bundled crypto-js and crc-32 libraries. Nothing you hash leaves your machine, and the page keeps working offline once loaded. The public API runs the same logic module on the server through the Node bridge, so only direct API callers send text to the server, where it is processed in memory, not stored, and rate-limited to 30 requests per minute for anonymous callers.

FAQ

Can I reverse a hash to get the original text?

No. MD5, SHA-1, SHA-256 and SHA-512 are one-way, and CRC32 and Adler-32 discard almost all of the input, so no tool can turn a digest back into data. The only practical approach is guessing: the Hash Cracker tests a digest against wordlists of common inputs, and the Hash Identifier suggests which algorithm produced an unknown digest.

Why does my SHA-256 differ from the one in my terminal?

Almost always a trailing newline. echo abc | sha256sum hashes the four bytes abc\n and prints edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb, while this page hashes exactly what you typed and gives ba7816bf...15ad. Use printf '%s' abc | sha256sum or echo -n to drop the newline, and watch for CRLF line endings or a byte order mark in files.

Which hash should I use for passwords?

None of these six. They are fast by design, which lets an attacker test billions of guesses per second against a leaked digest. Use a slow, salted password-hashing scheme instead: the Argon2 Generator is OWASP's first choice, with scrypt where Argon2id is unavailable, Bcrypt for legacy systems and PBKDF2 where FIPS-140 compliance is required.

Is my file or text uploaded when I hash it?

No. Both input modes are processed entirely in your browser, and no request carrying your text or file is made while you use the page. The server sees your data only if you call the JSON API directly, which accepts text, not files.

References

API Usage Example:

POST /api/tools/crypto/hash
Content-Type: application/json

{
    "text": "abc",
    "algorithms": [
        "md5",
        "sha1",
        "sha256",
        "sha512",
        "crc32",
        "adler32"
    ],
    "outputFormat": "hex"
}
Ready