What is a GPU stress test?
A GPU stress test applies sustained graphics work so you can observe how a rendering workload behaves over time. This browser GPU stress test sends a procedural fragment shader to WebGL 2 and records browser frame intervals while it runs. The useful questions are specific: does frame delivery stay consistent, do long intervals become frequent, and does the browser report a graphics error or lose its rendering context?
The scope is this page and its browser graphics path. Desktop stress software can exercise different APIs, larger memory allocations, and system telemetry that a web page cannot access. A smooth online run does not establish hardware health, overclock stability, or performance in a particular game. For a lighter browser scheduling check without this shader workload, use the [FPS tester](/) or FPS stability test.
How to stress test your GPU online
Save important work and close unnecessary graphics-heavy tabs. Keep the browser visible on the display you want to observe. The static preview does not run the shader; only Start test begins the workload. Choose Stress Test for sustained observation, or Benchmark for the locked three-round procedure. Configuration stays locked during a run so a result does not silently mix different loads.
- In Stress Test, choose Low first and select 30 seconds. The other durations are 1, 5 and 15 minutes on devices without conservative limits.
- Select Start test. Allow the two-second warm-up to finish before interpreting the measurements.
- Watch frame times and the visible shader. Stop ends future submissions; a hidden page or changed viewport also ends the run.
- Read the completed or partial summary. Download JSON or CSV to retain configuration, definitions, events and measured samples before starting another run.
How this WebGL GPU stress test works
One full-screen triangle invokes a fragment shader for each drawing pixel. Each fragment samples a three-dimensional procedural field along a ray, combining trigonometric field evaluations into a visible luminous shell. The loops have fixed upper bounds, and every fragment executes the selected step and field-iteration counts. More pixels and more evaluations increase the submitted arithmetic work; there are no thousands of independent objects or draw calls intended to inflate CPU overhead.
Low uses 384 × 216 drawing pixels with 24 ray steps and one field iteration per step. Medium uses 640 × 360, 40 steps and two iterations. High uses 960 × 540, 56 steps and three iterations. Extreme uses 1280 × 720, 72 steps and four iterations. These sizes ignore device pixel ratio and remain fixed throughout a run. Work increases by construction, but elapsed time need not scale proportionally: drivers, graphics hardware and browser scheduling differ.
WebGL 2 is the implemented rendering engine. The support panel separately reports whether the WebGPU API is exposed; this version does not request a WebGPU adapter or implement that backend. An exposed API alone does not establish a working device. If WebGL 2 is unavailable, the tool displays an unsupported state instead of running an animation substitute.
Understanding FPS and frame-time results
Current FPS is 1000 divided by the mean of the latest 60 valid frame intervals in the current round. Average FPS uses the mean interval across all retained measurement samples. Frame time beside Current FPS uses the same recent window. These intervals come from consecutive requestAnimationFrame timestamps: they approximate browser scheduling and presentation opportunities, not pure GPU execution or confirmed physical screen presentations.
The 1% Low FPS needs at least 100 samples. It converts the mean of the slowest ceil(sample count × 0.01) intervals to FPS, rather than reporting one worst frame. Jitter is the median absolute deviation from the median frame interval, in milliseconds; zero deviations count. Median, P95 and P99 frame times describe the center and slower tail using linear interpolation. Read them with the sample count: a short partial run offers less evidence than a completed observation.
The charts group valid intervals into approximately one-second buckets and plot reciprocal mean interval as FPS alongside mean frame time. Warm-up produces no points, and separate benchmark rounds are not connected. Pause chart updates freezes the display while measurement continues. GPU draw time, when available, is a separate asynchronous timer-query median around sampled shader draws. It is not a device-wide utilization reading. Missing or invalid timing stays N/A.
Stress Test versus GPU Benchmark
Stress Test maintains your selected load for the selected duration. Benchmark instead locks Medium at 640 × 360, 40 ray steps and two field iterations, with a static scene and three ten-second measurement rounds. Each round receives a fresh two-second warm-up. Workload, shader and measurement-method versions are included in exports. The render size, scene and per-draw work are fixed; the number of draws completed during the fixed observation time is measured rather than predetermined.
The benchmark summary reports each round’s sample count, average FPS, frame-time distribution and available GPU draw-time distribution, plus the median of completed-round average FPS values. Without valid GPU timers, interpret it only as a browser presentation comparison under a fixed graphics workload. There is no cross-device score or leaderboard. Match backend, versions, dimensions, iteration counts, browser, display setting and power conditions before comparing repeats; an interrupted run is labeled partial.
Choosing a duration and intensity
A useful GPU stability test starts with an observation you can comfortably stop. Run Low briefly before raising intensity between runs. Longer duration can reveal changes over time, but no duration proves permanent stability. Extreme requires an explicit acknowledgment because it submits substantially more work. Touch-first devices and devices reporting at most 4 GB of memory are limited to Low or Medium and at most one minute of stress measurement; these are conservative heuristics, not measurements of GPU capability.
The tool stops after four consecutive intervals longer than 250 ms, or one interval of at least two seconds, including during warm-up. Ordinary slow measured frames remain in the results; a two-second measurement gap is excluded and recorded as an interruption. It also stops at 120,000 valid intervals to bound memory. Stop prevents new draws and releases controlled resources, but a browser cannot promise to instantly cancel a command already queued in a driver. Reduced-motion preference keeps the shader scene static and pauses live chart updates by default.
Why FPS may drop under load
Additional shader work may take longer to render, but the GPU is not the only possible bottleneck. Display refresh and VSync often cap browser callbacks even when graphics capacity remains. CPU scheduling, browser extensions, background work, power settings and browser throttling can change frame delivery. Thermal throttling is a possible system behavior, but a falling FPS curve alone cannot identify it or measure temperature.
Repeat under controlled conditions and change one variable at a time. A stable average with occasional tall frame-time peaks describes a different pattern from sustained slower delivery. Compare the frame-time tool for browser cadence without this graphics scene, or use FPS drop analysis for its separate relative-spike method. Neither comparison can isolate a defective component by itself.
What browser GPU tests cannot measure
Web pages cannot reliably read general GPU temperature, hardware power, full VRAM use, real GPU utilization, or every driver-level fault. This GPU stress test does not infer any of those from FPS. Optional elapsed GPU queries describe sampled draw commands, not theoretical compute throughput or memory health. Context-loss events report a browser graphics interruption without diagnosing whether memory pressure, a driver reset, browser policy or another cause was responsible.
No hardware model or unmasked renderer identifier is collected. Downloads include browser family/version for comparison and stay local; the page does not upload results or use session-recording analytics. An export describes one observation with its limitations, not a pass/fail certificate. The methodology documents sampling, exclusions and timer invalidation so those limits remain attached to the interpretation.
Troubleshooting a stopped or unsupported run
If WebGL 2 is unavailable, review browser graphics acceleration settings or try another current browser. A shader compilation or linking error can depend on the browser and driver; the test stops rather than presenting fabricated measurements. A blank scene, resource-allocation error or lost graphics context is a reason to stop, close other graphics tabs and retry at Low. Updating the browser or driver may help, but the page cannot diagnose the underlying system.
Switching tabs, locking a phone, rotating the device or resizing the window ends the active run. The hidden gap and any resumed transient are not stitched into the results; start a new observation instead. Context restoration never restarts the workload automatically. For severe stutter, allow the browser to respond to Stop before trying again. Review the event list and export partial results if the interruption itself is relevant.
Frequently asked questions
Does this GPU stress test run automatically?
No. The initial graphic is a static preview. Support detection may create a temporary graphics context but submits no shader workload. Start test is the only control that begins rendering work.
Why is GPU draw time N/A even though the scene runs?
The browser may omit the timer extension, queries may not have completed, or a timer-disjoint event may have invalidated the round. Frame intervals can still be measured. They are not substituted for GPU time.
Can a steady 60 FPS result mean my GPU has unused capacity?
Yes. The browser commonly schedules animation near the active display cadence. A steady capped rate does not tell you how much graphics capacity remains. Compare fixed-load GPU timings where available and retain the display conditions.
Can I use this to validate an overclock or diagnose overheating?
A browser observation cannot validate an overclock, certify stability or diagnose overheating. Use appropriate system telemetry and tests for that purpose. Stop if the computer behaves abnormally; no temperature is measured here.
Why can two benchmark runs disagree?
Browser version, display cadence, power mode and competing system work may differ. Compare all three round distributions and valid sample counts. An interrupted result or changed configuration should not be treated as the same observation.
What happens to my results when I leave?
The workload stops and controlled graphics resources are released. Results are held only in page memory, so download JSON or CSV first if you need a record. No account, result upload or ranking service is involved.