How to use the Hash Identifier
Identify a hash in three steps:
1
Paste your hash
Paste any hex or base64 hash string into the input field. The length and character set are analyzed immediately.
2
Review the candidates
The tool displays ranked algorithm candidates. The 'Best match' is highlighted at the top. Each result shows the confidence level, security status, bit size, and common usage context.
3
Use the example hashes
Click any pre-computed example in the Quick Test panel to load a known hash and see how the identification works for MD5, SHA-1, SHA-256, SHA-384, and SHA-512.
When to use this tool
Use this tool when you encounter an unknown hash and need to identify its type:
- →Identifying the hash algorithm used in a database password field when documentation is missing or unclear
- →Forensic analysis — determining which hash function was used in a legacy system before migration
- →CTF (Capture the Flag) security challenges where hash identification is part of the puzzle
- →Code review and security audits — quickly identifying whether a stored hash is using a broken algorithm like MD5
- →Debugging hash mismatches by confirming the algorithm used by an external API or third-party system
- →Educational purposes — verifying hash output lengths match expectations for different algorithms
Frequently asked questions
Q:Can a hash identifier always determine the exact algorithm used?
No — hash identification is probabilistic, not definitive. Multiple algorithms can produce the same output length. For example, both SHA-256 and SHA3-256 produce 64 hex characters, and both SHA-512 and Whirlpool produce 128 hex characters. The identifier ranks candidates by how commonly each algorithm produces that length in practice, assigning High confidence to the most likely match. Context always matters: a 64-character hash from a Linux /etc/shadow file is almost certainly SHA-256, while the same length from a Solidity contract context is likely Keccak-256. Use this tool to narrow down candidates, then confirm with context.
Q:How does hash length relate to the algorithm?
Hash output length in hex characters is directly determined by the algorithm's output bit size: MD5 = 32 chars (128 bits), SHA-1 = 40 chars (160 bits), SHA-224/SHA3-224 = 56 chars (224 bits), SHA-256/SHA3-256/Keccak-256/BLAKE2s = 64 chars (256 bits), SHA-384/SHA3-384 = 96 chars (384 bits), SHA-512/SHA3-512/Keccak-512/Whirlpool/BLAKE2b = 128 chars (512 bits). Each hex character encodes 4 bits, so bits / 4 = hex length. This tool uses these length-to-algorithm mappings as the primary identification signal.
Q:What should I do if I find an MD5 or SHA-1 hash in my codebase?
Finding MD5 or SHA-1 hashes in production code is a security finding that warrants investigation. First, determine the context: are these hashes used for checksums/fingerprinting (lower risk) or for authentication/passwords/certificates (high risk)? For password storage, immediate migration to bcrypt, Argon2id, or scrypt is critical. For digital signatures or certificates, migration to SHA-256 should be prioritized. For non-security checksums, assess whether the threat model includes adversarial tampering — if yes, upgrade to SHA-256; if no (e.g., simple data deduplication), the risk is lower but upgrading is still best practice.
Q:Why does the identifier show multiple candidates for the same hash?
Multiple candidates appear when the hash length matches more than one known algorithm. For example, a 64-character hex string could be SHA-256, SHA3-256, Keccak-256, or BLAKE2s — all produce 256-bit (64 hex char) outputs. The confidence levels reflect real-world usage frequency: SHA-256 gets High confidence at 64 chars because it is vastly more common than the alternatives. Medium-confidence candidates are real but less common. Low-confidence candidates are technically possible but rarely encountered outside specialized systems. Eliminate candidates by checking the application context where the hash was found.
Q:Can this tool identify bcrypt, Argon2, or scrypt password hashes?
Not currently — these password hashing functions produce structured output with embedded parameters, not plain hex strings. A bcrypt hash looks like $2b$12$... (60 characters with dollar-sign delimiters and Base64 encoding), Argon2 looks like $argon2id$v=19$m=65536,t=3,p=4$..., and scrypt uses a similar parameter-prefixed format. These are not hex hashes and this tool focuses on identifying plain hex hash strings. The identifier does detect hex strings that may be intermediate hashes used inside these functions (like raw SHA-512 outputs from PBKDF2 pre-processing), but the full PHC string format requires a dedicated password hash identifier.
Q:Why does Keccak-256 appear as a candidate for 64-character hashes when it's Ethereum-specific?
Keccak-256 is listed as a candidate for 64-character hashes because it's encountered frequently enough in modern systems — particularly in Ethereum smart contract development, Web3 tooling, and blockchain applications — to warrant Medium confidence. Any tool that interacts with Ethereum (wallets, indexers, explorers, Solidity compilers) will produce Keccak-256 hashes. If you're analyzing a hash from a blockchain context and it's 64 hex chars, Keccak-256 is often the correct identification even though SHA-256 is listed as High confidence. The important distinction: Keccak-256 and SHA3-256 produce different values even though both are 64 chars.