SHA-1 Hash Generator

Produce the SHA-1 digest of any text as 40 lowercase hex characters, computed by your browser's own crypto. For legacy compatibility, not security.

🌐 Español

🔒 Private by design: your text is processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

A fingerprint, not a lock

A hash takes any amount of data and produces a fixed length value that is easy to compute forwards and infeasible to run backwards. SHA-1’s is 160 bits, written as forty hexadecimal characters.

The word people reach for is fingerprint, and it is a good one. Two identical documents share a digest. Change a single character, a single byte, even the case of one letter, and the digest changes completely rather than slightly, with no visible relationship to the previous value.

What a hash is not is encryption. There is no key and no way back. If you need to recover the original text later, hashing is the wrong operation entirely.

Getting a digest

  1. Paste or type your text into the box. The action button is disabled while it is empty.
  2. Click SHA-1 Hash Generator.
  3. The forty character digest appears in the read-only box under a Done! line.
  4. Click Copy to clipboard.
  5. Process another clears both boxes for the next value.

Whitespace counts. A trailing newline picked up when you copied from a terminal changes the digest, and that is the usual explanation when your value does not match somebody else’s for text that looks identical.

Why SHA-1 is no longer a security primitive

The property that makes a hash useful for proving what you have is collision resistance: it should be infeasible to find two different inputs with the same digest.

SHA-1 no longer has it. Weaknesses were identified in the mid-2000s, and in 2017 researchers published two genuinely different PDF documents with an identical SHA-1 digest, produced deliberately rather than found by luck. That result ended SHA-1’s usefulness for signatures and certificates, and the costs have only come down since.

The practical consequence is specific. Any system where a SHA-1 digest is used to say this is the document I approved can be attacked by preparing two documents in advance, getting one signed, and substituting the other. Certificate authorities stopped issuing SHA-1 certificates and browsers reject them outright.

For anything security relevant, SHA-256 Hash Generator is the drop-in answer, and SHA-512 Hash Generator if you want a longer digest from the same family.

The uses that survive

None of that makes SHA-1 useless, and the honest framing is that it failed at one job while remaining fine at others.

Where a digest is only being used to detect accidental change rather than deliberate substitution, collisions are not the threat model. A build system checking whether a file changed since the last run, a cache key, a deduplication index: an attacker who can craft colliding inputs is not part of any of those pictures.

Plenty of long lived systems also simply use SHA-1 as their identifier scheme and are not going to change. When you need to match one of those values, you need SHA-1 and no substitute will do. That is what this page is for.

Bytes, not characters

The single most common reason two tools disagree about a digest is encoding.

Hash functions consume bytes. Text is not bytes until something decides how to represent it, and different tools have historically decided differently. The text you type here is converted to UTF-8 before hashing, which is the modern default and what almost everything else uses today.

For plain ASCII it makes no difference. For an accented character, a symbol, an emoji or any non-Latin script it makes all the difference, because those become two, three or four bytes each and a tool using a legacy single byte encoding produces an entirely different digest from the same visible text.

If you are comparing against a value from another system and the two disagree on text containing anything outside plain ASCII, encoding is the first thing to check.

For a file rather than typed text, File Checksum reads the raw bytes, which is the only correct way to fingerprint a binary. For an even older algorithm still found in download pages, MD5 Hash Generator is the equivalent page and carries a similar warning.

When the goal is authentication rather than a bare digest, HMAC Generator combines a key with the message, which is what API request signing actually needs. And if you are preparing a value for a URL or a header, URL Encode and Base64 Encode handle the transport layer. The rest is on the dev tools hub.

See it in action

Screenshot of the SHA-1 Hash Generator tool with the sample input “Everything on SysFenix runs in your browser. You…”
SHA-1 Hash Generator mid-process: the sample input “Everything on SysFenix runs in your browser. You…”.
Screenshot of the SHA-1 Hash Generator result screen showing the generated output “438aeff58ea3816a79fad714aa9b41cbe329641b”
The finished result: the generated output “438aeff58ea3816a79fad714aa9b41cbe329641b”. The download link is a local blob URL — the file never leaves your device.

Frequently asked questions

How long is a SHA-1 digest?

Forty lowercase hexadecimal characters, always, whatever you feed it. That is 160 bits written two hex digits per byte across twenty bytes. A single character and a novel produce outputs of exactly the same length, which is one of the defining properties of a hash and the reason a digest cannot be reversed to recover its input.

Is SHA-1 safe to use for passwords or signatures?

No. A practical collision was demonstrated in 2017, meaning two different inputs that produce the same digest can be constructed on purpose. That breaks every use where the digest is meant to prove which document you have. Certificate authorities stopped issuing SHA-1 certificates years ago and browsers reject them. Use SHA-256 for anything where security matters, and a purpose built password hash for passwords.

So why does this tool exist?

Because plenty of systems still legitimately use SHA-1 for non-security work and you occasionally need to match one. Older checksum manifests, version control object identifiers, some API request signing schemes and a great deal of legacy tooling all speak SHA-1. Verifying that your value matches theirs is a compatibility task, not a security one.

Does the digest depend on how the text is encoded?

Very much so, and it is the most common cause of two tools disagreeing. Hashes work on bytes, not characters, so the text is converted to UTF-8 first. An accented letter, an emoji or any non-Latin script becomes several bytes, and a tool that used a different encoding will produce a completely different digest from the same visible characters.

Where does the hashing happen?

In the browser's own cryptographic implementation, reached through the standard Web Crypto interface. There is no hashing library shipped with the page and no request made anywhere. The same code path runs under the project's automated tests against the published reference vectors, so the implementation is checked against an external source of truth rather than only against itself.

Can I hash a file with this?

Not here. This page takes typed or pasted text, and pasting a binary file into a text box will not give you the file's digest, because the bytes are mangled on the way in. Use the dedicated checksum tool for files, which reads the raw bytes.

Why is my digest of an empty box not shown?

Because the action button stays disabled while the box has no characters in it. The empty string does have a well defined SHA-1 digest, and it is a useful thing to recognise since it appears whenever a process has hashed nothing at all, but you cannot produce it here without typing something.

Related tools