How Fast Can Your Computer Crack a Password? CPU vs GPU Explained

I wanted this experiment to answer a question that a password-strength meter cannot answer on its own: what does your computer actually do when it tries password candidates? A green bar and an impressive number of years are easy to draw. Generating a candidate, calculating its hash, comparing it and counting only completed work is much more interesting.

The Password Cracking Lab does that work locally. You choose an invented password, a search strategy and CPU, GPU or Hybrid mode. Your browser hashes the target, and separate workers try to recover it without receiving the original text. There is no password upload and no pretend cracking animation. If you stop before a match, that is the result.

01 — An offline attack is a different experiment

When you sign in to a website, the service decides whether an attempt is allowed. It can delay repeated failures, limit requests, require a second factor or lock a session. An offline attacker who has obtained a password hash can instead test guesses against that hash without asking the login service for permission each time.

That difference is the starting point for this lab. It deliberately creates a fast, unsalted SHA-256 hash of your fictional target inside your browser. The workers enumerate guesses against that local teaching hash. They do not connect to an account, bypass a login screen, download breached databases or probe a remote computer.

A successful recovery here does not mean someone can sign in to your bank with the same technique. Conversely, MFA does not make a leaked password hash impossible to guess. It can add an independent requirement at the actual login. Offline storage protection and online account protection address different parts of the problem.

02 — Hashes are not encrypted passwords

Encryption is designed to be reversed by someone holding the appropriate key. A cryptographic hash produces a fixed-size digest and has no decryption key. SHA-256 produces 256 bits whether its input is a short word or a long message. Finding a password candidate is not the same operation as decrypting that digest.

For each candidate, the experiment calculates SHA-256 and compares all eight digest words with the target. If they match, the coordinator regenerates that indexed candidate and checks it independently on the CPU and with Web Crypto. Only then does the interface announce recovery. It never compares guesses directly with the original password.

The crucial question is therefore not “can I reverse 256 bits?” It is “how many plausible inputs must I try, and how expensive is each attempt?” A strong hash does not turn a small, predictable input space into a large one. The enormous space of possible SHA-256 outputs is not the space of three-digit passwords.

03 — Dictionaries, patterns and exhaustive search

A dictionary attack tries a predefined collection of plausible words before exploring every possible string. Our lab bundles an original teaching dictionary of 64 words, including katharina. It can add title case, uppercase and numerical suffixes from one to four digits. Leading zeroes are included.

That is why katharina2482 can be recovered when those options are selected. The entry already exists in the dictionary; the suffix comes from systematic enumeration. The lab does not read the entered password and secretly add its name or adjust suffix length. The example buttons visibly set useful configurations, just as you could set them yourself.

Numeric search enumerates all digit strings of each selected length. Brute force enumerates strings from your chosen digits, lowercase letters, uppercase letters and ASCII symbols. Its order is deterministic. Smart mode starts with words and short numbers, then tries suffixes, longer numeric strings and finally the selected brute-force phases.

The table under the dashboard makes that order inspectable. A completed numeric phase says something precise about numbers of that length. It says nothing about accented letters, emoji, a word absent from the dictionary or longer strings. A stopped experiment does not become a strength certificate.

04 — Search-space arithmetic comes before speed

For a fixed length L and an alphabet containing A characters, the exhaustive space contains A^L candidates. If multiple lengths are enabled, their spaces are added. Leading zeroes matter: 007 is a three-character candidate, distinct from 7.

These are search counts, not measured cracking speeds. A person-chosen password is also not necessarily uniform over its nominal character set. Choosing a familiar name and appending a date creates a different guessing problem from generating a unique random password of the same length.

The lab keeps indices and totals as JavaScript BigInt values. That matters when a space exceeds the largest exactly representable ordinary JavaScript integer. The display may round a percentage or duration, but candidate indexing and completed-range accounting remain exact.

05 — CPU, GPU and Hybrid do real work

CPU mode uses dedicated Web Workers, keeping candidate generation and hashing off the main interface thread. You can limit worker count and computational intensity. More workers can increase throughput, but also compete with the rest of your computer. A laptop running on battery deserves a different setting from an idle desktop.

GPU mode requests a WebGPU adapter and device, compiles a WGSL compute shader and runs actual SHA-256 rounds in parallel. Each invocation checks one encoded candidate. The browser still has to prepare input buffers, upload them, schedule the shader and retrieve its answer. All of that is part of the practical cost.

The GPU is not guaranteed to win. Small batches, transfer overhead, browser scheduling, the selected adapter and the rest of your workload can change the result. This lab measures completed work instead of displaying a fixed “GPU multiplier.” Software-only adapters are disabled in the normal interface, and unavailable WebGPU disables both GPU and Hybrid mode.

Hybrid mode runs CPU and GPU workers concurrently. One shared coordinator assigns different indexed ranges to each engine and hands out more work as an engine completes a batch. Neither engine silently switches into the other mode. A lost GPU ends the run with an explicit error rather than reporting subsequent CPU work as GPU performance.

Candidate preparation for the GPU still uses a worker's CPU; “GPU” means the SHA-256 candidate checks execute in the shader. That distinction is useful when interpreting small-search results or comparing this browser exercise with mature native tools such as John the Ripper.

06 — An estimate is not a promised finding time

Before an attack, the lab warms up the engines separately and measures actual batches. It divides the configured candidate count by measured throughput to estimate a complete traversal. During the attack, measured results update that estimate. No three-second success sequence or invented hardware rate is built in.

The location of a matching candidate is unknown to the search engine. It might be near the beginning, near the end, or outside the space entirely. Dividing the space by two would only describe an expected position under additional assumptions; it would not tell us when your particular invented password will be found.

Changing the password alone therefore does not necessarily change the initial full-search estimate. With the same configuration, you are asking the machine to traverse the same space. Predictable names and suffixes become cheap only when an appropriate strategy places those candidate patterns early.

Calibration counts are separate from attack counts. Warm-up is excluded from the measured calibration counter. CPU and GPU calibration contributions share one real wall-time window, including intensity rests, so their sum represents the measured combined rate. During an attack, current rates use completed candidates in a rolling wall-time window; the final average uses confirmed attempts divided by elapsed attack time.

All dispatched candidates in a completed batch count, even if one lane found a match. Other engines may already be processing their own ranges. The counter does not pretend every worker stopped at the exact instant of the first matching hash. Initialization, calibration, deliberate pauses and final independent verification are excluded from attack elapsed time.

07 — Real password storage should make guessing expensive

SHA-256 is deliberately fast. That is useful for many cryptographic tasks, but an unsuitable property for password storage on its own. Our teaching hash deliberately removes the expensive parts so visitors can observe real searches without waiting for a production password-storage workload.

A unique salt distinguishes each stored password hash and prevents one precomputed lookup from applying identically to every account. It does not turn a predictable password into an unpredictable one or prevent guesses against an individual known hash.

Modern password hashing such as Argon2id adds configurable computation and memory cost. Those costs affect how many guesses an attacker can process simultaneously. A fast SHA-256 rate from this lab is not an Argon2id cracking rate, and there is no honest universal conversion factor between the two.

When building an application, use a maintained password-hashing implementation and current storage guidance, then choose suitable parameters for your service. This exhibit explains the distinction; it does not provide a production password-storage design.

08 — Try it without confusing the conclusions

1. Open the lab and choose the invented 123 example. It explicitly selects numeric lengths 1–3.
2. Measure performance, then start. Watch confirmed candidates and elapsed time, rather than assuming the pre-run estimate is the expected finding time.
3. Try katharina2482 with dictionary suffixes enabled. Inspect the completed phases.
4. Change the configuration to a deliberately small incompatible space and observe truthful exhaustion.
5. If a physical WebGPU adapter is available, compare modes with the same search and intensity settings. Repeat measurements if your device's load changes.

A longer search has no automatic demo cutoff. Pause waits for assigned batches to complete and preserves the in-memory session. Resume continues from the same ledger. Stop ends the computation, and Reset clears the target-related session and any revealed result.

The page pauses a running search when the tab is hidden. A closed, suspended or throttled browser is not a reliable background compute service. Long runs also consume energy and produce heat; choose conservative settings on phones and laptops. The supported generated candidates are ASCII, 1–24 characters. That explicit boundary matters more than a reassuring short-run result.

09 — Use the experiment to improve real habits

A password manager helps you generate and keep unique passwords instead of inventing predictable variations of one base word. Reuse creates a separate risk: a credential exposed at one service can be tried at another without anybody needing to crack a fresh hash.

Passkeys can replace shared password secrets for supporting services, and appropriately implemented authentication can resist phishing. Where passwords remain, use unique generated credentials and enable a suitable second factor. Protect recovery channels and the device holding your credentials too.

The useful lesson is the relationship between search order, input predictability, hash cost and measured hardware performance. A short successful recovery demonstrates one real comparison process. An unsuccessful run tells us only what that process actually checked. That is a better foundation than a green “secure” label.

Sources and further reading

The experiment's implementation and limits are documented in the repository. These primary references cover the hash, browser APIs and password-storage distinctions discussed here.

• NIST FIPS 180-4: Secure Hash Standard
• W3C: WebGPU Shading Language
• MDN: WebGPU adapter requests and availability
• OWASP: Password Storage Cheat Sheet
• RFC 9106: Argon2
• NIST SP 800-63B: Authentication and authenticator management

Your password. Your hardware. Your privacy. Open the lab →