WebGPU: modern graphics and compute in the browser
WebGPU gives web apps direct, modern access to the graphics card for 3D rendering and for general computation such as machine learning. What it is and where it stands.
For more than a decade, WebGL was the way to reach the graphics card from a web page. It is based on OpenGL ES, a design from an earlier generation of hardware. Modern graphics cards work differently, and native apps moved on to Vulkan, Metal and Direct3D 12 long ago.
WebGPU brings that modern model to the web. It is not a newer WebGL. It is a new API, built on those native systems.
What is different from WebGL
| WebGL | WebGPU | |
|---|---|---|
| Based on | OpenGL ES | Vulkan, Metal, Direct3D 12 |
| State handling | One global state machine | Explicit pipelines and resources |
| General computation | Only through workarounds | Compute shaders built in |
| Shader language | GLSL | WGSL |
| CPU overhead | Higher | Lower, with more draw calls per frame |
Two differences matter most.
Lower overhead. WebGPU validates work up front and batches commands, so complex scenes with many objects keep a steady frame rate.
Compute shaders. The graphics card can run general calculations, not only drawing. That makes browser-side machine learning, physics and large data processing practical.
The first lines of a WebGPU app
async function initGpu(canvas) {
if (!navigator.gpu) return null; // not supported: use a fallback
const adapter = await navigator.gpu.requestAdapter();
if (!adapter) return null;
const device = await adapter.requestDevice();
const context = canvas.getContext("webgpu");
context.configure({ device, format: navigator.gpu.getPreferredCanvasFormat() });
return { device, context };
}
From there you create buffers, write shaders in WGSL, build a pipeline and issue draw calls. The API is explicit, which means more code than WebGL for a simple triangle and far more predictable performance for a real scene.
Most teams use a library
Few projects write raw WebGPU. Three.js and Babylon.js have WebGPU renderers, and the machine learning libraries for the browser, such as TensorFlow.js, ONNX Runtime Web and Transformers.js, can use it as a backend. You often get the benefit by changing one setting.
What people build with it
- 3D on product pages: configurators and viewers with realistic lighting.
- Games with larger scenes than WebGL handled comfortably.
- Data visualization with millions of points.
- Machine learning in the browser: image and speech models that run on the user's device, with no data sent to a server and no inference bill.
- Image and video effects in real time.
Where it stands
Chrome and Edge have shipped WebGPU since 2023. Safari and Firefox followed, and coverage across operating systems and older devices is still filling in. Check current support for the platforms your users are on.
That makes one rule non-negotiable: detect it and fall back.
const gpu = await initGpu(canvas);
if (!gpu) startWebGLRenderer(canvas);
Should you care now?
If your product involves 3D, heavy visualization or on-device AI, yes. Prototype with a library that can switch between WebGL and WebGPU, and measure on real devices. For a content site or a typical business app, there is nothing to change. WebGPU is a capability to keep in mind for the day a feature needs it.