Text Hash Calculator (SHA-256 / SHA-1)
Instantly compute SHA-256 and SHA-1 hashes of text or passwords in your browser. Nothing is sent to a server.
(enter text above)
(enter text above)
Other Tools
Related articles
📖 Where people get stuck
Computes SHA-256 and SHA-1 of the text you type, in the browser, using the Web Crypto API. Nothing is uploaded. Hashing is not encryption — it is not that the key to reverse it is missing, but that the information needed to reverse it was discarded. That is not the same as being safe, though: where the set of possible inputs is small, computing them all and comparing recovers the original immediately.
| Case | What happens | What to do |
|---|---|---|
| Using SHA-256 to store passwords | SHA-256 is designed to be fast. For checking file integrity, faster is better — but use it to store passwords and that speed becomes the attacker weapon. A modern GPU computes billions of SHA-256 operations per second, so an eight-character alphanumeric password falls to brute force within hours. Adding a salt does not change this: a salt defeats rainbow tables and stops identical passwords hashing identically, but it has no effect whatsoever on how fast a single account can be brute-forced. | Use bcrypt, scrypt or Argon2id for passwords. These are deliberately slow and deliberately memory-hungry — the memory part matters, because a GPU has little memory per compute unit, which erases its parallelism advantage. Do not roll your own SHA-256 with a salt and ten thousand iterations: the instinct is right, but that construction is already standardised as PBKDF2, and a hand-written implementation always gets something wrong. As of 2026 the recommendation is Argon2id, falling back to bcrypt where your language or framework does not offer it. |
| The same text gives a different hash elsewhere | A hash function receives bytes, not characters. So text that looks identical produces a completely different result if a single byte differs. In practice the cause is nearly always one of four things: a trailing newline, LF versus CRLF, the presence of a BOM, or UTF-8 versus a legacy encoding. The shell is the classic case — echo "abc" | sha256sum hashes four bytes including the newline, not the three bytes of abc. |
In a shell, use printf %s abc | sha256sum, which appends nothing (avoid echo -n, whose behaviour varies by environment). When two values disagree, start by counting the bytes on each side — wc -c or xxd exposes a one-byte difference instantly. A failing API signature check almost always has the same root: verify the order in which the signing string was assembled, the separators, any trailing newline, and whether re-serialising the JSON changed the key order or the whitespace. Comparing the actual bytes, rather than assuming they must be the same, is the only way through. |
| Still using SHA-1 as it is | SHA-1 collisions are not a theoretical matter: in 2017 Google and CWI published two PDFs with different content and the same SHA-1 (SHAttered). By 2020 a chosen-prefix collision was within practical cost, which is the much stronger attack of colliding two documents while keeping each one whatever you want it to say. Git still uses SHA-1 because being able to construct a collision and being able to attack Git are different problems, not because SHA-1 is sound. | Use SHA-256 or stronger for anything new. For existing SHA-1, judge by what it is used for: tamper detection, signatures and certificates need migrating, whereas ETags, cache keys and sharding — where a collision costs you nothing — are not urgent. The distinction matters, because trying to replace every SHA-1 uniformly leaves you no capacity for the places that are genuinely dangerous. The test is a single question: would an attacker gain anything by deliberately forcing a collision here? If not, leave it; if so, fix it first. |
Hashing something does not make it anonymised. Sharing the SHA-256 of an email address or a phone number as though it were no longer personal data is dangerous: phone numbers come from a finite space — under a billion possibilities for Japanese mobiles — so computing them all and matching recovers the original in minutes. Email addresses fall the same way against a list of known addresses. This is exactly the route that became a problem in the advertising industry, and hashing only anonymises when the input space is effectively unbounded. If you genuinely need a matching identifier, use an HMAC with a secret key, which denies the brute-force to anyone without the key — at the cost of taking on key management as a new responsibility. Before adopting a design that publishes hashes as identifiers, actually estimate how many hours it would take to enumerate that input space.
📖 How to Use
-
1
Type the text to hashType or paste the text you want to hash into the input field. SHA-256 and SHA-1 values are calculated in real time as you type.
-
2
Review the hash valuesSHA-256 (256-bit / 64 hex chars) and SHA-1 (160-bit / 40 hex chars) are shown. Choose the algorithm appropriate for your use case.
-
3
Copy and useClick the Copy button next to each hash to copy it. Use it for file integrity checks, API signature verification, or comparing against known values.
❓ Frequently Asked Questions
Should I use SHA-256 or SHA-1?
Are hash values one-way?
Is my input sent to a server?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.