CPU Stress Test
Spawns Web Workers that run a tight SHA-256 loop via crypto.subtle. Each worker loads one logical thread; totals show combined throughput and help spot thermal throttling. Runs entirely in your browser — nothing is uploaded.
2
Logical cores
0
Total ops/sec
0
Avg per thread
0.0
Elapsed (s)
0
Peak ops/sec
How to use
- Open the page on the machine you want to test (desktop or laptop, plugged in or on battery — note which).
- Set Thread count to match
navigator.hardwareConcurrency(shown as Logical cores) or lower to isolate a subset. - Choose Duration — 20–60 seconds for a quick burst; 120+ seconds to watch sustained thermal drop-off.
- Click Start stress and watch Total ops/sec, Peak ops/sec, and per-thread bars.
- Click Stop early if the machine gets too hot, or let the timer finish.
- Use Copy results to save numbers for support tickets or before/after comparisons on the same browser.
FAQ
Is it safe to run a browser CPU stress test?
For a few minutes on a healthy machine, yes — the test only runs JavaScript in isolated Web Workers. It will raise CPU temperature and fan speed. Avoid on low battery, in hot rooms, or if your device already overheats. Stop immediately if the system becomes unstable.
Why SHA-256 instead of a simple empty loop?
Each hash feeds the next digest through crypto.subtle, keeping the main thread free while workers stay busy with async crypto work. That pattern loads logical cores similarly to real crypto-heavy web tasks without blocking UI rendering on the main thread.
Why do ops/sec drop after 30–60 seconds on my laptop?
That is often thermal throttling or battery power limits. Thin-and-light laptops frequently hold peak ops/sec for 20–40 seconds, then step down 30–50% as the CPU hits its thermal envelope. The drop itself is a useful datapoint — not a bug in the test.
Can I compare these numbers to Cinebench or Geekbench?
No. Native benchmarks use compiled SIMD and tuned loops that are much faster than JavaScript SubtleCrypto. Numbers here are only meaningful across runs on the same machine and browser — ideal for spotting throttling, a regression after an OS update, or differences between performance and efficiency cores.
Why do some threads show half the ops/sec of others?
On hybrid CPUs (Intel 12th-gen+, Apple Silicon, mobile SoCs), performance cores run faster than efficiency cores. Spawning one worker per logical core often shows P-cores at roughly 1.5–2× the ops/sec of E-cores by design.
Does anything leave my browser?
No. Workers are created from an inline script blob in this tab. No data is uploaded, logged, or stored on our servers.
When should I use a browser CPU stress test instead of Cinebench?
When you need a quick, install-free check in the browser you actually use — verifying all logical cores respond, comparing power modes on the same day, or attaching Copy results to a support ticket. Use Cinebench or HWiNFO when you need absolute scores, temperature, or clock speeds.
Can I use this on a work laptop without installing software?
Yes. Many IT policies block .exe benchmarks but allow normal browsing. This runs entirely in the tab. Still get permission before sustained load on managed or shared machines.
Introduction
CPU Stress Test loads your processor from inside the browser using Web Workers — one worker per configured thread — each running a tight SHA-256 loop through crypto.subtle. The main thread stays responsive while workers report operations per second (ops/sec) so you can see total throughput, per-thread balance, and whether speed holds or falls over time.
Use it to:
- Sanity-check that all logical cores participate under load
- Spot thermal throttling or battery power caps (peak then sustained drop)
- Compare before/after on the same PC and browser (OS update, power mode, background apps)
- See P-core vs E-core imbalance on hybrid CPUs
This is not a replacement for Cinebench, Geekbench, or HWiNFO. It measures JavaScript crypto throughput in Web Workers, which is a useful relative signal — not an absolute CPU score.
How the test works
1. Thread model
When you click Start stress, the tool:
- Reads
navigator.hardwareConcurrency(shown as Logical cores) — the browser’s estimate of parallel hardware threads, usually matching logical CPU count. - Spawns N Web Workers (your Thread count, default N = logical cores, max 128).
- Each worker receives a start command with a wall-clock end time (
performance.now() + duration).
Workers are created from an inline script blob (Blob + URL.createObjectURL). No external worker file is fetched.
2. Work loop (SHA-256)
Inside each worker:
seed → SHA-256 → use digest as next input → repeat until time expires
- Initial input:
"mega-cpu-stress-seed-" + threadId - Each iteration:
await crypto.subtle.digest("SHA-256", data)then replacedatawith the 32-byte hash - Ops counts completed digests
- Every ~500 ms, the worker posts
{ id, ops, ts }to the main thread
The loop is async (await per hash). Throughput depends on how fast the browser’s SubtleCrypto backend runs on that core — typically well below native OpenSSL benchmarks but consistent for same-browser comparisons.
3. Main-thread aggregation
The main thread:
- Updates stats every 250 ms
- For each worker message, computes instantaneous rate:
(ops_now − ops_prev) / (ts_now − ts_prev) - Total ops/sec = sum of per-thread rates
- Avg per thread = total ÷ thread count
- Peak ops/sec = highest total seen during the run
- Elapsed = time since start (stops at duration or Stop)
Per-thread progress bars scale each thread against the fastest thread in the current snapshot (visual balance, not GHz).
4. Stop conditions
The test ends when:
- The configured duration elapses (workers exit their loop and terminate on cleanup), or
- You click Stop, or
- You leave the page (
beforeunloadterminates workers)
Understanding each output
Logical cores
What it is: Value of navigator.hardwareConcurrency on this browser session (minimum fallback 4 if missing).
How to read it:
| Scenario | Example | Meaning |
|---|---|---|
| 8-core / 16-thread desktop | 16 |
Hyper-threading counted — default thread count should be 16 |
| Apple M2 (8 cores) | 8 |
Often 4 P + 4 E presented as 8 logical workers |
| Old or privacy browser | 4 (fallback) |
API missing — set thread count manually to your known core count |
| VM with limited vCPU | 2 or 4 |
Reflects what the guest OS exposes to the browser |
Not measured: Physical cores vs threads, cache size, or which core is P vs E (infer from per-thread ops/sec spread).
Total ops/sec
What it is: Sum of all active workers’ current SHA-256 digest rates (hashes per second, aggregated).
How to read it:
| Pattern | Example | Likely cause |
|---|---|---|
| Stable plateau | ~420,000 total for 60s | Good cooling, AC power, desktop |
| Peak then −30–50% | 500k → 280k after 40s | Thermal throttling or laptop power limit |
| Low flat line | 50k on 16 threads | Background tab throttling, very low power mode, or heavy OS contention |
| Rises briefly then flat | First 5s climb | JIT/warm-up + scheduler settling — normal |
Key point: Compare peak vs end-of-run on the same browser after the same idle period. Cross-machine or cross-browser totals are not comparable.
Avg per thread
What it is: Total ops/sec ÷ thread count at the latest tick.
How to read it:
| Scenario | Output | Meaning |
|---|---|---|
| Uniform cores | All threads within ~10% | Homogeneous cores or few threads |
| Hybrid CPU | Some threads ~2× others | P-cores vs E-cores — expected on Intel 12th+ / Apple Silicon |
| One thread near zero | Thread 3: 12k, others 180k | OS pinned a worker to a saturated core, or a core parked — retry or reduce threads |
| Thread count > logical cores | Lower avg, higher total may still rise | Oversubscription — context switching, not extra hardware |
Elapsed (s)
What it is: Seconds since Start stress until now (or stop).
How to read it: Runs toward your Duration target. If you stop early, elapsed reflects actual run length. Use with peak/sustained comparison: e.g. “peak at 12s, 40% drop by 45s.”
Peak ops/sec
What it is: Highest Total ops/sec observed during the session (including partial runs after Stop).
How to read it:
| Use case | What to look for |
|---|---|
| Thermal test | Peak in first 20–40s, then current total well below peak × 0.7 |
| Regression check | Peak dropped 20% after OS update on same laptop |
| Power modes | Peak on battery vs plugged-in (often 40–60% lower on battery) |
The tool may show a note when current total is < 70% of peak — a hint for throttling, not a diagnosis.
Per-thread ops/sec (bars)
What it is: Each worker’s instantaneous hash rate and a bar scaled to the fastest thread in that tick.
How to read it:
| Visual | Interpretation |
|---|---|
| All bars similar height | Symmetric load (or all E-cores if count matches E-core count only — rare at default) |
| Two tiers of heights | Classic hybrid core behavior |
| One bar lags intermittently | Scheduler or thermal limit on that logical processor |
| Bars shrink together over time | System-wide throttle (heat or power) |
What this test measures
| Measured | How |
|---|---|
| Relative JS SubtleCrypto SHA-256 throughput | Ops/sec per worker and sum |
| Multi-thread participation | Whether N workers all report non-zero rates |
| Sustained vs burst behavior | Peak vs late-run total ops/sec |
| Hybrid core imbalance | Spread across per-thread rates |
| Browser tab / power side effects | Drops when backgrounded or on battery (indirect) |
What this test does NOT measure
| Not measured | Why |
|---|---|
| CPU temperature (°C) | Browsers cannot read thermal sensors |
| Clock speed (GHz) | No access to MSR / cpufreq |
| Cinebench / Geekbench score | Different runtime (native SIMD vs JS crypto) |
| Single-core vs multi-core official rating | No standardized workload |
| GPU load | Workers are CPU-only |
| RAM bandwidth or latency | Working set is tiny (32-byte hash chain) |
| Disk, network, or PCIe | Not touched |
| Absolute cross-browser ranking | V8 vs SpiderMonkey SubtleCrypto backends differ |
| Fan speed or power draw (Watts) | No OS hooks from the page |
| Definitive “CPU health” | High ops/sec does not prove longevity; throttling is not always failure |
Treat ops/sec as a browser-local stress signal, not a certification benchmark.
Interpreting thermal and throttling patterns
The most informative pattern is full-speed burst → sustained drop:
- 0–30 s: Total ops/sec climbs to peak (fans spin up).
- 30–90 s: Total falls 30–50% while elapsed continues — common on ultrabooks (e.g. MacBook Air, slim Windows laptops) in a warm room.
- Plateau: New lower steady state — CPU reduced clock to stay within TDP.
Plugged in vs battery: Many laptops cap PL1 on battery; peak may be half of AC power without any hardware fault.
Background tab: Chromium may throttle timers and workers in background tabs — run the test in the foreground tab.
Safety and responsible use
- Run for minutes, not hours, unless you deliberately burn-in (and accept heat wear).
- Ensure ventilation — do not cover laptop vents.
- On shared or remote machines, get permission before maxing CPU.
- Stop if the system freezes, shuts down, or throttles so hard the browser becomes unusable.
- Close unnecessary apps for cleaner baseline; or leave them open to reproduce “real world” contention.
Common use cases
Below are situations where people reach for a browser-based CPU stress test — no download, no admin rights, same tab you can screenshot or Copy results from.
1. New or refurbished machine — “Are all cores alive?”
Goal: Confirm the OS and browser see the expected core count and every logical processor does work under load.
How to run:
- Leave Thread count at Logical cores (e.g.
16on a Ryzen 7 desktop,8on a MacBook Air M2). - Duration: 30–60 seconds.
- Watch Per-thread throughput — every bar should move; none should sit at
0ops/sec.
Healthy signal: Total ops/sec stable or slowly settling; all threads report similar tier (or two tiers on hybrid CPUs — see case 6).
Red flags: One thread permanently near zero, total ops/sec far below a second run on the same machine, or logical cores mismatch what you ordered (e.g. VM capped at 2 vCPU).
2. Laptop feels slow when hot — thermal throttling check
Goal: See whether performance drops after a burst because the chassis cannot sustain full TDP.
How to run:
- Plug into AC power first (repeat on battery for comparison).
- Duration: 90–120 seconds in a normal room (not cold garage).
- Note Peak ops/sec in the first 30s vs Total ops/sec at the end.
Healthy signal (thin laptop): Some drop is normal — e.g. peak 480k → sustained 320k on a Dell XPS 13 after 45s.
Red flags: >50% drop within 20s every time, or sharp cliff plus loud fan / shutdown — may need cleaning, new paste, or warranty check (this tool does not read °C; use feel + ops pattern only).
3. Before vs after — OS update, driver, or “optimization” app
Goal: Same machine, same browser, same power mode — did peak or sustained ops/sec change?
How to run:
- Baseline: copy results after a 60s run (document Windows Balanced vs Best performance, macOS Low Power off, etc.).
- Apply update or toggle setting.
- Reboot if the change requires it, idle 2–3 minutes, run again with identical Thread count and Duration.
What to compare: Peak ops/sec, end-of-run Total ops/sec, and per-thread spread — not cross-browser totals.
Example: Windows 11 24H2 vs previous build on the same Chrome profile; 12% lower peak after update is worth investigating background apps or new power defaults.
4. Power mode and battery vs wall power
Goal: Quantify how much performance your laptop leaves on the table on battery or in eco mode.
How to run:
| Run | Settings | Duration |
|---|---|---|
| A | AC + Performance / Best performance | 60s |
| B | AC + Balanced / Energy saver | 60s |
| C | Battery + same mode as A | 60s |
Typical pattern: Run C peak is 40–60% of Run A on many ultrabooks — expected, not a defect.
Use when: Choosing whether to plug in for video calls, compiling in the browser, or long web-app sessions.
5. Cooling pad, stand, or desk change
Goal: Cheap A/B test — does better airflow improve sustained ops/sec (not just peak)?
How to run:
- Same room, same duration (120s), same thread count.
- Run once flat on desk, once with pad/stand/lid riser.
- Compare ops/sec at elapsed 90s, not only peak.
Healthy signal: Sustained total 10–20% higher with pad — airflow helped.
Limit: One variable at a time; close other heavy apps for both runs.
6. Hybrid CPU — performance vs efficiency cores
Goal: Understand why “8 cores” does not mean eight equal speeds (Intel 12th-gen+, Apple M-series, Snapdragon laptops).
How to run:
- Thread count = logical cores.
- Duration: 30s — enough for bars to stabilize.
Expected: Two height tiers in Per-thread throughput — faster P-cores, slower E-cores (often ~1.5–2× ratio). That is architecture, not a broken core.
Use when: Explaining task manager behavior, choosing “efficiency” vs “performance” battery modes, or teaching how schedulers spread web workers.
7. Remote support and help desk — quick load without installing tools
Goal: Ask a user to open a link and paste Copy results instead of walking them through installing Prime95 or HWiNFO.
How to run:
- User: default threads, 30s run, copy text to ticket.
- Support: check logical core count matches device spec, all threads non-zero, peak not absurdly low for class of machine.
Good for: “Computer feels sluggish,” suspected background miner (compare idle vs stress — user should close unknown apps first), or confirming browser is not stuck in power-save.
Not good for: RMA proof alone — pair with vendor diagnostics or temperature tools when hardware failure is suspected.
8. VM, cloud desktop, or Citrix session — vCPU exposure
Goal: Verify how many logical processors the guest browser actually gets.
How to run:
- Open tool inside VM/RDP/browser isolation.
- Read Logical cores and per-thread bars.
Example: AWS WorkSpaces reported 4 logical cores; all four bars active — matches instance type. If you paid for 8 vCPU but see 4, fix allocation before blaming “slow CPU.”
9. Browser or profile comparison (same PC)
Goal: See if one browser throttles workers more aggressively (extensions, enterprise policy, battery saver).
How to run:
- Same machine, same power mode, within minutes: Chrome vs Firefox vs Edge, each 60s run.
- Compare Peak and sustained totals.
Interpretation: Differences of 10–25% are common (engine + SubtleCrypto path). Huge gap in one browser only → try clean profile or disable extensions.
Do not use to: Rank “fastest browser in the world” across different hardware.
10. Short burn-in after repair or dust cleaning
Goal: 2–3 minute load to verify stability after repaste, fan swap, or heat-pipe service — still in-browser, no install.
How to run:
- Duration: 120s, AC power, good ventilation.
- Run twice with a 2-minute cool-down between.
Healthy signal: Second run peak within ~5–10% of first; no browser crash or system reset.
Stop if: Artifacts, hard freeze, or repeated emergency shutdown — use proper stress tools and warranty channels for hardware sign-off.
11. Classroom, demo, or interview — show multi-threading
Goal: Visual proof that one web page can use many cores via Workers (training, blog screenshot, conference demo).
How to run:
- Project screen; start with 1 thread, then increase to full logical cores — show Total ops/sec scaling (sub-linear is normal due to overhead and hybrid cores).
- Point at per-thread bars when teaching parallelism vs concurrency.
Tip: Reduce duration to 20s for live demos; mention thermal warning before starting.
Quick reference — which settings for which goal
| Goal | Thread count | Duration | Focus metric |
|---|---|---|---|
| All cores working | = Logical cores | 30–60s | Per-thread bars all > 0 |
| Thermal throttle | = Logical cores | 90–120s | Peak vs end Total ops/sec |
| Power mode A/B | = Logical cores | 60s | Peak ops/sec |
| Single-core-ish load | 1 | 30s | One bar only |
| Oversubscription test | 2× logical cores | 60s | Total vs avg/thread |
| Support ticket | Default | 30s | Copy results text |
Related tools
- Device Info —
hardwareConcurrency, platform, and battery context for the same session. - Memory Test — tab heap usage and allocation stress on Chromium browsers.
- GPU Stress Test — graphics load; different subsystem from CPU Workers.
- WebRTC Leak Test — network/WebRTC exposure, not CPU throughput.