SHA-1 Hash Generator & Verifier
Generate SHA-1 hashes from text or files and verify them against an expected checksum. Streams large files in your browser, supports UTF-8/UTF-16/Latin-1/Windows-1252 and hex/base64 input, HMAC-SHA1, and hex or base64 output. SHA-1 is collision-broken: use it for legacy compatibility and checksums only.
SHA-1 is cryptographically broken
Practical collisions exist: SHAttered (2017) produced two different PDFs with the same SHA-1, and chosen-prefix collisions followed in 2019 for well under $100,000 of compute. SHA-1 is still fine for checksums against accidental corruption and for legacy compatibility (Git object IDs, old TOTP/HMAC-SHA1 deployments) — but never for passwords, digital signatures, certificates, or integrity against an attacker. Use SHA-256 for integrity and signatures, and Argon2id for passwords.
Runs entirely in your browser. Text is hashed with the native Web Crypto API and files are streamed through WebAssembly — nothing is uploaded, nothing is logged. Verify it yourself: open DevTools → Network, hash a 2 GB file, and watch zero requests appear.
SHA-1 digest
0 bytes hashed — canonical empty-input digestFix the input above to see a digest.
Input
0 characters · 0 encoded bytes
UTF-8 is what sha1sum and Git use. Leave it selected unless you are reproducing a legacy system's hash.
Compare against an expected hash
Paste the publisher's checksum — bare hex, base64, a sha1sum line (hash filename) or a BSD SHA1 (file) = hash tag all work.
The verdict appears as soon as both a digest and an expected hash exist. Works for text and files — the browser equivalent of sha1sum -c.
Other algorithms
Compute MD5, SHA-1, SHA-256 and SHA-512 of the same input to identify an unknown digest. Loads a small WebAssembly module (for MD5) on demand — that is why it is opt-in.
Never store passwords as SHA-1
Beyond the collision attacks, SHA-1 is simply far too fast: commodity GPUs compute tens of billions of SHA-1 hashes per second, so a leaked table of SHA-1 password hashes is cracked in hours, salted or not. Password storage needs a deliberately slow, memory-hard function: Argon2id, bcrypt (cost ≥ 12), scrypt or PBKDF2 with 600,000+ iterations. The one SHA-1 password use that is still respectable is the k-anonymity lookup in Have I Been Pwned's breach API — where the hash is a search key, not a credential store.
Why two tools disagree about "the" SHA-1 of your text
- • A trailing newline.
echo "abc" | sha1sumhashes 4 bytes, not 3. Useecho -nor this tool's trailing-newline toggle. - • A BOM. UTF-16 (and sometimes UTF-8) files from Windows editors start with 2–3 extra bytes that most online tools silently add and CLIs never do.
- • The encoding itself. "café" is 5 bytes in UTF-8, 4 in Latin-1, 8 in UTF-16 — three different digests for the same visible text.
- • Byte order. UTF-16LE and UTF-16BE hold the same characters in opposite byte order and therefore hash differently.
- • Git object IDs. A Git blob hash is not the SHA-1 of the file: Git hashes
blob <size>\0followed by the content, which is whygit hash-objectandsha1sumnever agree.
Technical specifications
- • Algorithm: SHA-1, 160-bit output (FIPS 180-4, RFC 3174), published 1995
- • Output: 160 bits = 20 bytes = 40 hex characters = 28 base64 characters
- • Block size: 512-bit blocks, Merkle–Damgård construction with length padding
- • Empty input: SHA-1 of zero bytes is
da39a3ee5e6b4b0d3255bfef95601890afd80709 - • Security status: collision resistance broken (SHAttered 2017, chosen-prefix 2019); preimage resistance still holds, which is why HMAC-SHA1 remains usable
- • Text engine: native
crypto.subtle.digest(Web Crypto API) - • File engine: hash-wasm streaming SHA-1, 4 MiB chunks, constant memory use
- • Verification: hex compared case-insensitively, base64 compared case-sensitively (base64 is a case-significant alphabet)
Where SHA-1 is still legitimately used
About SHA-1 Hash Generator & Verifier
The SHA-1 Hash Generator & Verifier computes 160-bit SHA-1 digests of text or files and checks them against a hash you already have. Text is hashed live as you type with the browser's native Web Crypto API; files are streamed through WebAssembly in 4 MiB chunks, so a multi-gigabyte archive is hashed without ever being loaded into memory. Input can be interpreted as UTF-8, UTF-16LE, UTF-16BE, ISO-8859-1, Windows-1252, raw hex or base64 bytes, and the digest can be read as lower-case hex, upper-case hex or base64.
Why use a SHA-1 Hash Generator & Verifier?
Most online SHA-1 tools quietly make one of three mistakes: they prepend a byte-order mark to UTF-16 input, they refuse empty input (so you can never see the canonical da39a3ee… digest), or they lowercase both sides when verifying — which breaks base64 comparison, because base64 is case-significant. This tool does none of those. It hashes exactly the bytes you asked for, allows empty input, streams real files instead of pretending text is enough, and tells you which format it compared and why the verdict came out the way it did. It is also explicit about what SHA-1 may and may not be used for.
Who is it for?
Developers working with Git object IDs and legacy SHA1SUMS files, engineers debugging TOTP and HMAC-SHA1 request signatures, security teams auditing systems that still depend on SHA-1, and anyone migrating old SHA-1 fingerprints to SHA-256 who needs both digests of the same bytes side by side.
How to use the tool
Choose Hash Text to hash typed input, or Hash File to checksum a file from disk.
In text mode, type or paste your input — the 40-character SHA-1 digest updates live above the input box, and an empty box shows the canonical empty-input digest da39a3ee5e6b4b0d3255bfef95601890afd80709.
Pick the input encoding: UTF-8 (the default, and what sha1sum and Git use), UTF-16LE/BE, ISO-8859-1, Windows-1252, or raw hex/base64 bytes.
If you are reproducing a hash from a file that starts with a byte-order mark, tick 'Prepend a BOM'; leave it off to match command-line tools.
Tick 'Append a trailing newline' when reproducing echo "text" | sha1sum, which hashes an extra LF byte that echo -n does not add.
Turn on 'Keyed mode: HMAC-SHA1' and enter a key when you need a TOTP-style or legacy webhook signature instead of a plain digest.
In file mode, drop a file onto the drop zone — the progress bar shows percentage and MB/s while the file is streamed through SHA-1 in chunks.
Paste the expected checksum into 'Compare against an expected hash' for a green match / red mismatch verdict; bare hex, base64, a sha1sum line or a BSD SHA1 (file) = hash tag are all accepted.
Frequently Asked Questions
How do I generate a SHA-1 hash of text or a file?
In text mode, type into the input box — the 40-character hex digest appears immediately and updates on every keystroke; there is no Generate button. Choose an input encoding first if your source is not UTF-8, because the digest is taken over bytes, not characters. In file mode, drop a file onto the drop zone: it is read in 4 MiB chunks and fed through a streaming SHA-1, so nothing is uploaded and nothing is held in memory in one piece. Both modes produce results identical to sha1sum, shasum -a 1 and Get-FileHash -Algorithm SHA1 on the same bytes.
What is the SHA-1 hash of an empty string?
da39a3ee5e6b4b0d3255bfef95601890afd80709, or 2jmj7l5rSw0yVb/vlWAYkK/YBwk= in base64. It is the digest of zero bytes, so it is also the checksum of every empty file — sha1sum /dev/null prints exactly that value. It shows up as a placeholder in legacy APIs and as the tell-tale sign that a pipeline hashed nothing at all: an unread stream, a failed download, an empty buffer. Note that Git's hash of an empty blob is different (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391) because Git prefixes the content with a "blob 0\0" header before hashing.
Is it safe to hash sensitive data in this tool?
Yes, in the privacy sense. The tool runs entirely in your browser: text is hashed with the native Web Crypto API (crypto.subtle.digest) and files are hashed by a WebAssembly module served from this site. Your input never reaches a server, is never logged and is never stored. Verify it without trusting us: open DevTools, switch to the Network tab, hash a large file and watch zero requests appear. Algorithm safety is a separate question — SHA-1 is collision-broken, so never treat a SHA-1 digest as proof that data was not tampered with.
Is SHA-1 broken, and what should I use instead?
SHA-1's collision resistance is broken. The 2017 SHAttered attack produced two different PDFs with the same digest, and 2019's chosen-prefix collisions brought the cost under $100,000 — cheap enough for a well-funded attacker. Browsers, TLS and code-signing ecosystems removed SHA-1 years ago. It remains acceptable for checksums against accidental corruption and for legacy compatibility, but never for passwords, signatures, certificates or integrity against an adversary. Use [SHA-256](/tools/sha256-hash-generator-verifier/) for integrity and signatures, and [Argon2id](/tools/argon2-hash-generator-verifier/) or [bcrypt](/tools/bcrypt-hash-generator-verifier/) with cost 12+ for passwords.
Why doesn't my UTF-16 SHA-1 match another tool's?
Almost always a byte-order mark. Many online tools silently prepend FF FE (UTF-16LE) or FE FF (UTF-16BE) before hashing, which adds two bytes and produces a completely different digest. SHA-1 of "abc" as UTF-16LE without a BOM is 9f04f41a848514162050e3d68c1a7abb441dc2b5; with the BOM it is 5943831380243c1269c8b68bb92de6e2f1844590. This tool never adds a BOM unless you tick the checkbox. The second suspect is endianness — UTF-16LE and UTF-16BE hold the same characters in opposite byte order, so they never agree (UTF-16BE "abc" is af68535cb6d1af8b6e3c60305cf0bfae6c57de36).
Why does echo "abc" | sha1sum differ from hashing abc here?
echo appends a newline. "abc" is a9993e364706816aba3e25717850c26c9cd0d89d, but "abc\n" — what echo actually pipes — is 03cfd743661f07975fa2f1220c5194cbaff48451. Use printf '%s' abc | sha1sum or echo -n abc | sha1sum to hash three bytes, or tick this tool's 'Append a trailing newline' toggle to reproduce the four-byte version. The same class of bug bites text files: an editor that adds a final newline, or a Windows checkout storing CRLF instead of LF, changes the file's checksum without changing a single visible character.
How do I verify a file against a SHA1SUMS checksum?
Switch to Hash File, drop the file in, then paste the expected checksum into the compare box — a sha1sum line (hash, two spaces, filename) or a BSD SHA1 (file) = hash tag can be pasted whole. A green verdict means the bytes are identical to what was hashed originally. Because SHA-1 collisions are practical, treat the match as evidence against corruption, not against tampering: for real tamper protection verify a GPG signature over the checksum file, or ask the publisher for a [SHA-256](/tools/sha256-hash-generator-verifier/) sum instead.
Is HMAC-SHA1 still safe, and can I compute it here?
Yes to both. Switch on 'Keyed mode: HMAC-SHA1'. HMAC (RFC 2104) does not rely on collision resistance, so the SHAttered results do not break it — which is why TOTP and HOTP authenticator codes (RFC 6238 / RFC 4226), legacy webhook signatures and older AWS signing still use HMAC-SHA1 safely. New designs should still choose HMAC-SHA256. Never authenticate with sha1(secret ‖ message): SHA-1 is a Merkle–Damgård hash and is vulnerable to length extension. For more key formats and output encodings, see the [HMAC Generator & Verifier](/tools/hmac-generator-verifier/).
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.