SHA Hash Generator & Audit Workspace
Generate, verify, and analyze SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and SHA-3 family hashes. Features HMAC signature generation, file checksum auditing, input entropy analysis, and instant comparison.
Generate, verify, and analyze SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and SHA-3 family hashes. Features HMAC signature generation, file checksum auditing, input entropy analysis, and instant comparison.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
SHA — Secure Hash Algorithm — is a family of cryptographic hash functions designed by the NSA and standardized by NIST. A cryptographic hash function takes an input of any length and produces a fixed-length output called a digest or hash. The same input always produces the same hash. A single-bit change in the input produces a completely different hash. The hash cannot be reversed to recover the original input. These three properties — determinism, avalanche effect, and one-way irreversibility — are the foundation of how SHA functions are used in security systems.
SHA-1 produces a 160-bit hash displayed as a 40-character hex string. SHA-1 was the dominant hash algorithm for most of the 2000s but was officially deprecated by NIST in 2011 and withdrawn from security use after Google's SHAttered attack in 2017 demonstrated a practical collision — two different files producing the same SHA-1 hash. SHA-1 is still used in non-security contexts like Git commit IDs (though Git is transitioning to SHA-256) and legacy system checksums, but it must not be used for digital signatures, certificate fingerprints, or any security-sensitive integrity verification. SHA-256 produces a 256-bit hash (64 hex characters) and is currently the security standard — it is what TLS 1.3 uses, what code signing certificates use, and what the SHA-256 checksum files published alongside software downloads use. SHA-512 produces a 512-bit hash (128 hex characters) and provides a larger security margin — it is faster than SHA-256 on 64-bit hardware due to its 64-bit word operations and is used in some high-security contexts.
For new implementations, use SHA-256 as the default. SHA-256 is supported everywhere, fast on modern hardware, and provides security well beyond any currently known or foreseeable attack. Use SHA-512 when your application requires extra security margin or when profiling shows it is faster on your specific 64-bit server hardware. Never use SHA-1 for any new security implementation — it is cryptographically broken for collision resistance and its use in digital signatures, certificate fingerprints, and HMAC for security tokens is a vulnerability.
This tool generates a SHA hash for any text input using your chosen algorithm — SHA-1, SHA-256, or SHA-512. Paste or type any text into the input field, select the algorithm from the dropdown, click Generate SHA Hash, and the hex-encoded hash is displayed immediately. The output is the same hexadecimal string that the equivalent SHA function in your programming language's cryptographic library would produce: hashlib.sha256 in Python, crypto.createHash('sha256') in Node.js, MessageDigest.getInstance('SHA-256') in Java, or sha256.Sum256 in Go. The tool uses the browser's native Web Crypto API (SubtleCrypto.digest()) for all hashing operations. This is the same underlying cryptographic implementation used by browsers for HTTPS and Web Authentication. It means the hash values this tool produces are guaranteed to be correct — not a JavaScript reimplementation of SHA that might have subtle bugs, but the browser's own native cryptographic primitives used for real security operations. All hashing runs locally with no server involvement. Your input text — which might be a file path, a configuration value, a secret string you are debugging, or any other content — never leaves your browser tab. The hash appears in under a millisecond for typical text inputs. For very long inputs, hashing takes longer but still completes locally without transmitting any data. The generated hash can be copied to your clipboard with the copy button for use in checksums, comparison, documentation, or debugging.
1. Type or paste your text into the Input Text field — this can be any string: a plain word, a sentence, a JSON payload, an API response, a configuration value, or any other text content you want to hash. Be precise about what you paste: a trailing space, a newline character, or any other whitespace difference will produce a completely different hash. If you are trying to reproduce a hash from another system, make sure you are hashing the exact same byte sequence including any line endings.
2. Select the SHA algorithm from the Algorithm Selection dropdown — choose SHA-1 only for legacy compatibility with existing systems that require it, SHA-256 for all standard security use cases (file integrity, HMAC, digital signatures, checksums), or SHA-512 when you need a larger output or are working with a system that specifically requires it. If you are unsure, SHA-256 is the correct default for any new implementation.
3. Click Generate SHA Hash — the tool computes the hash using the browser's native Web Crypto API and displays the result as a lowercase hexadecimal string. SHA-1 produces a 40-character hex string. SHA-256 produces a 64-character hex string. SHA-512 produces a 128-character hex string. The result appears in under a millisecond for typical text inputs.
4. Compare the generated hash to the expected value if you are verifying or debugging — a hash mismatch means the inputs are different. Check your input for invisible differences: copy the input to a plain text editor to check for leading or trailing whitespace, verify the character encoding is UTF-8 if both systems should be using the same encoding, and confirm both systems are using the same algorithm (SHA-256 and SHA-256, not SHA-256 on one side and SHA-1 on the other).
5. Copy the hash output using the Copy button and use it in your application, security configuration, comparison script, or documentation — the hex string is ready to paste directly. For use as an HMAC key or in digital signature workflows, the hex hash can be used as the message digest component in the signature construction.
The scenario where I use a SHA generator most often during development is debugging a hash mismatch. Two systems that should agree on the hash of the same value are producing different results. This usually comes down to three things: a whitespace difference in the input (trailing newline, leading space, Windows line endings vs Unix line endings), a character encoding difference (UTF-8 vs UTF-16 vs Latin-1 producing different byte sequences for the same string), or the wrong algorithm being used (code that should use SHA-256 is actually calling SHA-1 because of a copy-paste error in the library configuration). Paste the exact input each system is hashing and compare — this tool shows you immediately whether the byte-for-byte input matches, because identical inputs always produce identical hashes. SHA-256 is also the algorithm behind most file integrity verification workflows. When you download a software package, a Docker base image, or any file distributed through an insecure channel, the publisher typically provides the SHA-256 checksum in a file alongside the download. Computing the SHA-256 of the downloaded file and comparing it to the published checksum tells you whether the file arrived intact and unmodified. This tool hashes text, not binary files — for file integrity verification, use sha256sum on Linux/macOS or certutil -hashfile on Windows. But for verifying string content from API responses, configuration values, or any text-based data, this tool provides that verification instantly. For developers learning about cryptographic security, this tool is also a live demonstration. Change one character in the input and watch the entire 64-character SHA-256 hash change completely — that is the avalanche effect. Hash the same input twice and confirm the output is always identical — that is determinism. Try to find two inputs that produce the same hash — you cannot — that is collision resistance. These are abstract concepts that become immediately concrete when you interact with the actual function.
Uses the browser's native Web Crypto API — hash values are computed using the same cryptographic implementation browsers use for HTTPS and Web Authentication not a JavaScript reimplementation
Algorithm selection — choose SHA-1 for legacy compatibility SHA-256 for standard security use or SHA-512 for higher security margin all from a single dropdown
Matches your application's library output — produces the same hex string as hashlib.sha256 in Python crypto.createHash in Node.js MessageDigest in Java and sha256.Sum256 in Go
100% browser-based — your input text never leaves your browser making it safe to hash sensitive strings configuration values and security-relevant content
Instant results — hashing completes in under a millisecond for typical inputs using native browser cryptographic primitives with no server round-trip
Well-known test vectors — the classic pangram input produces known reference hashes you can use to verify the tool matches your application's SHA output
Hex output ready to copy — the hash is displayed as a lowercase hex string ready to paste into your code documentation comparison script or security configuration
No account or installation required — generate SHA hashes immediately with no setup
Debugging hash mismatches between two systems that should produce the same SHA-256 output for the same input
Verifying the SHA-256 of a downloaded text file or string content against a published checksum
Generating SHA-256 hashes of configuration values or API secrets for use in integrity verification
Testing HMAC implementations by verifying the hash component of a MAC signature
Computing SHA-256 fingerprints of certificate or key material for comparison during security audits
Learning the difference between SHA-1 SHA-256 and SHA-512 output length and security properties
Generating checksums for content-addressed storage systems or cache keys
Verifying that an application's SHA hashing library produces the expected output for a known input
Example Input
The quick brown fox jumps over the lazy dog
Example Output
Input: "The quick brown fox jumps over the lazy dog" Algorithm: SHA-256 SHA-1 (40 chars): 2fd4e1c67a2d28fced849ee1bb76e7391b93eb12 SHA-256 (64 chars): d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592 SHA-512 (128 chars): 07e547d9586f6a73f73fbac0435ed76951218fb7d0c8d788a309d785436bbb642e93a252a954f23912547d1e8a3b5ed6e1bfd7097821233fa0538f3db854fee6 Note: These are well-known reference hashes for this pangram. They are used across security documentation to verify SHA implementations.
Empty Input: The tool requires at least one character of text to generate a hash. Hashing an empty string is technically valid and produces defined output (SHA-256 of an empty string is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855) but if the input appears empty and you expected content, verify your paste completed successfully.
Algorithm Mismatch: If you are trying to reproduce a hash from another system and the hashes do not match, verify both systems are using the same algorithm. SHA-1 SHA-256 and SHA-512 produce completely different outputs for the same input — they cannot be compared with each other. A SHA-1 hash is 40 hex characters, SHA-256 is 64 hex characters, and SHA-512 is 128 hex characters. Count the characters in the expected hash to determine which algorithm produced it.
Whitespace Difference Causing Hash Mismatch: SHA functions are extremely sensitive to input — a trailing newline, leading space, Windows CRLF line ending (versus Unix LF), or any other invisible whitespace character changes the hash completely. If your hashes do not match for what appears to be identical input, copy the input from both systems into a hex editor or character inspector to find invisible differences. This is the most common cause of hash mismatches in production systems.
Large Inputs Taking Longer Than Expected: For very large text inputs — pasting the contents of an entire file or a very long JSON payload — the SHA computation may take slightly longer than for small inputs. This is normal. The Web Crypto API processes input sequentially and larger inputs require more computation. For hashing actual binary files rather than text content, use sha256sum on Linux/macOS or certutil -hashfile filename SHA256 on Windows — command-line tools handle binary files correctly where browser-based tools may have character encoding conversion issues.
SHA-1 Producing an Incorrect or Unexpected Hash: If you are using SHA-1 for a legacy system integration and the output does not match the expected value, verify that the legacy system is also using pure SHA-1 rather than a variant like SHA-1 with a salt, HMAC-SHA-1 (which uses a key), or a double-hashing scheme. Pure SHA-1 has no key and no salt — it is just the hash of the raw input bytes. Any variation in the scheme produces a completely different output.
Using SHA-256 for password hashing in an application
Fix: SHA-256 is a fast hash function — modern hardware can compute billions of SHA-256 hashes per second. This makes it completely unsuitable for password hashing because an attacker who obtains a database of SHA-256-hashed passwords can brute-force them in seconds using GPU clusters. For password storage, use a purpose-built slow hash function: bcrypt, Argon2id, or PBKDF2 with a high iteration count (600,000+ iterations with PBKDF2-SHA256). These are designed to be computationally expensive so that brute-forcing is impractical. SHA-256 is the right tool for integrity verification, checksums, and HMAC — never for password storage.
Using SHA-1 for any new security implementation
Fix: SHA-1 is cryptographically broken. The SHAttered attack (2017) demonstrated a practical SHA-1 collision attack requiring approximately 6500 CPU-years of computation — expensive but feasible for well-funded adversaries. SHA-1 must not be used for digital signatures, certificate fingerprints, HMAC for authentication tokens, or any security-sensitive integrity verification. NIST deprecated SHA-1 for government use in 2011. The CA/Browser Forum banned SHA-1 TLS certificates in 2017. If you are maintaining a legacy system that uses SHA-1, migrate to SHA-256. Only use SHA-1 when you are required to interoperate with a legacy system that cannot be updated.
Comparing SHA hashes using case-sensitive string comparison when the cases differ
Fix: SHA hash functions produce a fixed bit pattern. When displayed as hexadecimal, some implementations use uppercase letters (A-F) and others use lowercase (a-f). The values d7a8fbb3 and D7A8FBB3 represent the same hash but will fail a case-sensitive string comparison. This tool always outputs lowercase hex. If you are comparing this tool's output against a hash from another system that outputs uppercase hex, normalize both to the same case before comparing. In most languages: hash1.toLowerCase() === hash2.toLowerCase() in JavaScript or hash1.lower() == hash2.lower() in Python.
Hashing user-provided data without input sanitization and using the hash as a unique key
Fix: If you use SHA-256 of user-provided content as a database key or cache key, a malicious user can craft inputs that produce hash values in a specific range to create database hot-spots, known as a hash flooding or hash collision denial of service attack. For security-sensitive key generation from user data, use HMAC-SHA-256 with a secret server-side key rather than plain SHA-256 — the secret key prevents attackers from predicting or controlling the hash output. For cache keys and non-security content addressing, plain SHA-256 is fine because the consequence of a collision is a cache miss, not a security failure.
Trusting that a SHA-256 match proves identity rather than just data integrity
Fix: A SHA-256 hash proves that a piece of data has a specific content — it does not prove who created it or whether the content is legitimate. If an attacker can replace both a file and its published SHA-256 checksum simultaneously (for example by compromising the download server), a matching checksum does not detect the attack. For true authenticity verification, the hash must be signed with a private key and the signature verified with the corresponding public key — this is what code signing and TLS certificate chains provide. SHA-256 alone is for integrity (detecting accidental corruption or tampering when the hash is distributed through a trusted channel), not for authentication.
JWT
Syntaxes and patterns for JSON Web Tokens: structure (Header.Payload.Signature), signing keys, validation, claims (sub, exp, iat), and storage.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
Is SHA1 still secure?
No. SHA-1 is considered cryptographically broken and must not be used for security-sensitive applications. The SHAttered attack published by Google in 2017 demonstrated a practical SHA-1 collision — two different PDF files with identical SHA-1 hashes. NIST deprecated SHA-1 for all government cryptographic applications in 2011 and the CA/Browser Forum banned SHA-1 TLS certificates in 2017. SHA-1 is still used in non-security contexts like legacy Git commit IDs but it must not be used for digital signatures, certificate fingerprints, HMAC authentication tokens, or any application where collision resistance matters.
What is the difference between SHA-256 and SHA-512?
Both are members of the SHA-2 family and are currently secure. SHA-256 produces a 256-bit hash (64 hex characters). SHA-512 produces a 512-bit hash (128 hex characters). SHA-512 provides a larger security margin but the practical security difference is not significant for most applications since SHA-256 is already far beyond any known or foreseeable attack. Performance varies by platform: SHA-512 is faster than SHA-256 on 64-bit hardware (because it uses 64-bit word operations) but slower on 32-bit hardware and some embedded systems. For new implementations, SHA-256 is the standard default. Use SHA-512 when your application specifically requires it or when you need maximum security margin.
Is it safe for sensitive data?
Yes. All hashing runs in your browser using the native Web Crypto API — your input text never leaves your machine and is never transmitted to any server. This is important when hashing values that contain sensitive content: API secrets, authentication tokens, internal identifiers, or any other data you would not want processed by a third-party service. Browser-based hashing with the Web Crypto API provides the same security as running the hash computation locally in your terminal.
Can I use SHA-256 for passwords?
No. SHA-256 is a fast hash function — hardware can compute billions of SHA-256 hashes per second, making brute-force attacks against SHA-256 password hashes trivially fast. For password storage, use a purpose-built slow hash function: bcrypt, Argon2id (the current OWASP recommendation), or PBKDF2-SHA256 with at least 600,000 iterations. These are designed to be computationally expensive even for short inputs specifically to resist brute-force attacks. SHA-256 is for data integrity and checksums — never for password storage or any scenario where the input might be a low-entropy value that could be guessed.
How do I compute SHA hashes in my application code?
In Python: import hashlib then hashlib.sha256(your_string.encode()).hexdigest() for SHA-256. In Node.js: const crypto = require('crypto') then crypto.createHash('sha256').update(yourString).digest('hex'). In Java: MessageDigest.getInstance('SHA-256').digest(yourString.getBytes(StandardCharsets.UTF_8)) then convert the byte array to hex. In Go: sha256.Sum256([]byte(yourString)) then fmt.Sprintf('%x', hash). In PHP: hash('sha256', yourString). Replace sha256 with sha1 or sha512 for the other algorithms. All of these produce the same hex output as this tool for the same input string with the same character encoding.
What is HMAC and how does it differ from a plain SHA hash?
HMAC (Hash-based Message Authentication Code) is a construction that uses a SHA function combined with a secret key to produce an authentication code. Unlike a plain SHA-256 hash which anyone can compute from the input, an HMAC-SHA-256 value can only be computed by someone who knows the secret key. This makes HMAC suitable for authentication — verifying that a message came from someone who knows the key and that the message has not been tampered with. HMAC is used for JWT signature verification, webhook signature validation, API request signing, and session token integrity. A plain SHA-256 hash provides data integrity (detecting accidental corruption) but not authentication (verifying the sender). Use HMAC when you need authentication; use plain SHA when you only need integrity.
Why do two identical-looking inputs produce different SHA hashes?
SHA functions are byte-for-byte sensitive — any difference in the actual bytes of the input, even invisible ones, produces a completely different hash. The most common sources of invisible differences are: trailing whitespace or newlines (many text editors append a newline at the end of a file), Windows vs Unix line endings (CRLF vs LF), different character encodings producing different byte sequences for the same characters (UTF-8 vs UTF-16 vs Latin-1), and BOM (byte order mark) characters prepended by some text editors. If two inputs look identical but hash differently, copy both to a hex editor to find the byte-level difference. Alternatively, hash each input and if the SHA-256 hashes match, the inputs are byte-for-byte identical — if they differ, there is a hidden difference.
What are SHA-3 and BLAKE2 and should I use them instead?
SHA-3 is the latest NIST hash standard published in 2015, using a completely different internal construction (sponge function) from SHA-2. It is not a replacement for SHA-2 — SHA-2 is not broken and NIST published SHA-3 primarily as an algorithm diversity option in case SHA-2 were ever attacked. SHA-3 is slower than SHA-2 in software and is not widely deployed. BLAKE2 (and its successor BLAKE3) is a faster alternative to SHA-2 designed for performance — it is faster than MD5 and SHA-256 on modern hardware while providing SHA-256-level security. BLAKE2 is used in password hashing schemes and file checksums where speed matters. For standard interoperability with existing systems, tools, and protocols, use SHA-256 — it is universally supported. Use BLAKE2/3 only if you specifically need a faster cryptographic hash and your deployment environment supports it.
Securing Your Web Applications: Essential Tools & Best Practices (2026)
Securing Your Web Applications: Essential Tools & Best Practices 2026. In-depth guide on password generators, JWT debuggers, hash tools, CSP validation, and real-world security strategies from a Principal Software Engineer with 15+ years experience.
How to Secure a Spring Boot Application in 10 Minutes: The 2026 Developer Security Checklist
A Spring Boot app can look production-ready and still expose dangerous defaults — from open actuator endpoints and weak JWT filters to hardcoded secrets, vulnerable dependencies, and unsafe SQL queries. This practical developer checklist walks through the exact 10-minute security checks you should run before deployment.
SQL Injection in Spring Boot (2026): Real Vulnerabilities, Prevention & Testing
Learn how SQL injection still breaks Spring Boot apps in 2026 with real Java vulnerabilities, blind SQLi examples, prevention checklists, and practical testing payloads.
Recent Activity
No recent activity