Bcrypt/Argon2 Hash
Decodes the cost parameters of a Bcrypt or Argon2 hash and explains what each one means.
Decoding is read-only text parsing — no hash is recalculated, no password is processed, nothing is sent to any server, not even Nexinon's. This tool never receives a plaintext password, only the already-computed hash someone pastes.
Why password hashing needs to be slow
Nexinon's Hash Generator covers MD5/SHA/BLAKE — algorithms that are fast on purpose, great for checking a file's integrity (a checksum). Bcrypt and Argon2 are the opposite: DELIBERATELY slow. The slowness is the protection itself — if a password database leaks, an attacker brute-forcing it (trying password after password) has to pay that slow cost on every single attempt, which makes testing billions of passwords expensive and slow. A fast hash used to store passwords would do the exact opposite: an attacker with a GPU would test billions of attempts per second.
How Bcrypt works
Bcrypt (1999, based on the Blowfish cipher) embeds three things in the hash string itself: the algorithm version (bug fixes over time), the cost factor (how many processing rounds — each +1 DOUBLES the work, since it's a power of 2) and the salt (a random value that guarantees the same password never produces the same hash twice, even for two users with an identical password). Bcrypt uses its OWN variant of Base64 to encode salt and hash — different from the standard Base64 (RFC 4648) used across nearly the rest of the web —, which has already tripped up more than one naive implementation that tried decoding with a regular Base64 decoder.
How Argon2 works
Argon2 (2015, winner of the Password Hashing Competition, now standardized as RFC 9106) has three variants — argon2i, argon2d and argon2id (hybrid, the default recommendation) — and three independent cost parameters: memory, time (iterations) and parallelism. Memory is the central innovation: every hashing attempt needs a real amount of memory available, not just compute power. That's what makes Argon2 far more expensive to attack at scale with a GPU than Bcrypt — GPUs have thousands of compute cores, but little memory available PER core.
What the "weak configuration" warning means
This tool's thresholds come from the OWASP Password Storage Cheat Sheet, the market's most-cited reference on the subject: Bcrypt with a minimum cost factor of 10 (12+ recommended); Argon2id with at least one of five equal-defense configurations (the most commonly cited minimum: 19 MiB of memory, 2 iterations, parallelism 1). A weak-configuration warning here doesn't mean the password itself is weak — it means the hashing algorithm is configured below what current market practice considers safe, which lowers the cost of a brute-force attack if the database leaks.
Frequently asked questions
No. This tool never receives a plaintext password — it only decodes the parameters already embedded in a Bcrypt or Argon2 hash you paste, without recomputing anything. To hash any text (including with HMAC), use the Hash Generator; to test the strength of a plaintext password, use the Password Checker.
No, and it never will — Bcrypt and Argon2 are one-way functions: there's no mathematical operation that reverses a hash back into the original password. This tool only reads the configuration PARAMETERS already visible in the hash's own text (version, cost, salt), never attempts to crack anything.
Because they serve opposite goals. MD5/SHA (Hash Generator) need to be fast to check a large file's integrity in milliseconds. Bcrypt/Argon2 store passwords — and the deliberate slowness is what makes brute-forcing billions of passwords too expensive to be worth it, even if the database leaks.
The cost factor is a base-2 exponent — factor 10 means 2¹⁰ = 1,024 rounds, factor 12 means 2¹² = 4,096 rounds (four times more work). That's how Bcrypt stays relevant even as hardware gets faster every year: just raise the cost factor to demand the same computation time as before.
Because Bcrypt uses its own symbol table ("./A-Za-z0-9", starting with a dot and a slash) instead of the standard RFC 4648 table ("A-Za-z0-9+/") — the bit-packing is identical to regular Base64, only the symbols used to represent each value change. A standard Base64 decoder will process the string without erroring, but silently return completely wrong bytes — exactly the kind of subtle bug this tool decodes correctly with the right alphabet.
The difference is HOW each one accesses memory during computation. argon2i accesses memory independently of the data being processed — more resistant to side-channel attacks, like timing memory access from a neighboring process on the same machine. argon2d accesses memory dependent on the data — more resistant to GPU/dedicated-hardware cracking, but more vulnerable to side-channel attacks. argon2id is hybrid (half of each approach), which is why it's the default recommendation, including by RFC 9106 itself and by OWASP.
No — not in the browser's localStorage, not on any server. As soon as you leave the page or clear the text, everything is discarded from memory.
Because that would be a completely different tool (a password cracker), with a purpose, misuse risk and implementation complexity that have nothing to do with this tool's goal — decoding and explaining the configuration PARAMETERS of an already-existing hash. To assess the strength of a plaintext password, use the Password Checker.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.