What this does
A cost factor tells you how slow one bcrypt hash is. This tool answers the follow-up question: what does that cost factor add up to across your actual traffic? Enter the measured time for one hash, your user count, and average logins per user per day, and it estimates total daily CPU time and the average number of CPU cores that would need to be dedicated to bcrypt alone to keep up.
It doesn't benchmark anything itself — it works from a per-hash time you already have. Get that number from Bcrypt Cost Calculator's live in-browser benchmark, or better, from timing bcrypt on your actual production server (see that tool's Node.js and Python snippets).
Why the core count is an average, not a provisioning target
The core-count estimate assumes logins are spread perfectly evenly across all 24 hours of the day — real traffic never is. A morning login rush, a post-outage reconnect storm, or just normal daytime-vs-overnight variation can put your actual peak load well above this daily average. Treat the number here as a floor: the least CPU you could possibly get away with, not what to actually provision. Size for your real peak-hour login rate instead.
FAQ
Is anything sent anywhere?
No — this is pure arithmetic that runs entirely in your browser.
Where do I get the per-hash time?
Bcrypt Cost Calculator benchmarks real bcrypt hashing live in your browser and extrapolates a time for any cost factor — a good starting point, though its own caveat applies here too: a browser benchmark isn't your production server. For the number that actually matters, time bcrypt on your real infrastructure using that tool's Node.js or Python snippet.
Why does the cost factor field not affect the math?
It's here for your own reference in the output sentence — the actual math runs entirely on the measured time you enter, since that already reflects whatever cost factor you measured it at.