WebGPU Fuzzing Test

What is this tool?

The WebGPU Fuzzing Test checks how robustly your browser's WebGPU stack handles a stream of randomised but reproducible workloads. It issues authentic WebGPU device calls — WGSL compilation, storage-buffer compute dispatches, render passes and resource churn — each wrapped in native error scopes, and counts what the driver reports.

The randomness is seeded and deterministic (a Mulberry32 generator), so the same seed reproduces the same run. Each iteration picks one of five workload types: a compute dispatch, a full-screen render, a texture create/write/render, a pipeline-churn stage that stresses the shader compiler and cache, and a buffer-churn stage that rapidly allocates and frees buffers.

This is a robustness probe, not a speed benchmark. It reports validation, shader and command errors, device-loss events and a categorical robustness verdict — and, being honest, it labels GPU timing as Unavailable when the browser does not expose it, and never claims temperature, power, clocks or VRAM.

How to use it

1. Confirm WebGPU is availableThe tool probes navigator.gpu and requests an adapter and device. If WebGPU is unavailable it shows a WebGPU Unavailable badge and an explanatory banner — there is no fallback path, so the test needs a WebGPU-capable browser.
2. Choose a mode and iteration countQuick (50 iterations), Standard (200), Extended (1000) or Custom. Custom iterations are clamped to 10-10,000. More iterations exercise more randomised cases.
3. Set intensity and balanceIntensity (light / medium / heavy / extreme) sets the per-tick work and compute size; the render/compute balance slides from pure compute to pure render; shader complexity runs 1-5. A fixed or random seed makes runs reproducible or fresh.
4. Run and watch the error scopesStart the run. Each iteration is wrapped in validation and out-of-memory error scopes and its GPU work is awaited, so errors are attributed to the workload that caused them. Pause, resume or stop at any point.

What the results mean

Robustness verdict

A category, not a number: Device Lost / Unstable if the device was lost, High Failure Rate if failed iterations exceed 10% of successes, Minor Validation Issues if any validation or shader errors occurred, otherwise Optimal Robustness.

Error counts

Validation errors (from the validation scope), shader errors (from WGSL getCompilationInfo), command errors (thrown exceptions), uncaptured errors and device-loss count are tracked separately, so you can see which layer complained.

Iteration timing

Average, fastest and slowest iteration time in milliseconds, plus successful and failed iteration counts. Average GPU timing is the mean submit-to-done wait and reads Unavailable when the browser exposes no real timing.

Resource tallies

Counts of render and compute passes run and pipelines, buffers and textures created, so the scale of the workload is visible alongside the errors.

What it can detect

• How robustly your WebGPU driver and WGSL compiler handle randomised, reproducible workloads
• Validation, shader-compilation and command errors, attributed to the workload that triggered them
• Device-loss events under compute, render, texture, pipeline-churn and buffer-churn stress
• Whether this browser exposes a working WebGPU adapter and device at all

Limits worth knowing

A browser can only report what the platform gives it. These are the honest boundaries of this page, so a result is never read as more than it is.

• It requires a WebGPU-capable browser and a secure context — Chrome or Edge 113+, or Firefox with WebGPU enabled. Without an adapter the test cannot run and says so; there is no WebGL fallback.
• It measures API and shader-compiler robustness inside the browser's security sandbox; as the tool states, it cannot guarantee low-level hardware stability.
• GPU timing here is a submit-to-done wait, not a hardware timestamp query, and is labelled Unavailable when the browser exposes no timing. It is not GPU temperature, power, clocks, utilisation or VRAM — none of which a browser can read.
• The verdict is categorical, not a score, and depends on the seed, mode and intensity — reproduce a run with the same seed to compare like with like.
• Adapter identity comes from requestAdapterInfo / adapter.info with generic fallbacks, so it may be less specific than a native tool would show.

Tips

• Fix the seed when you want to reproduce or share a run; use the random-seed button when you want to widen coverage across fresh cases.
• If you are chasing an intermittent WebGPU crash, raise the intensity and iteration count and watch the device-loss count and command errors rather than the timing.
• A verdict of Minor Validation Issues is worth reading the error breakdown for — it tells you whether the complaint came from validation, the WGSL compiler, or a thrown command.

Troubleshooting

Related documentation

• DisplayGPU BenchmarkRun a real browser-based graphics benchmark to measure your GPU rendering performance, FPS, frame time, and WebGL capability.
• DisplayShader Performance TestMeasure fragment-shader throughput with a real WebGL2 ray-marcher and a four-tier complexity sweep.
• DisplayVolume Shader BenchmarkA repeatable volumetric-shader benchmark with a warm-up, a transparent score and a controlled comparison mode.
• DisplayStress My GPUPush your GPU with a real WebGL2 ray-marching load and watch FPS, frame time and stability hold up — or drop off.