GPU & CPU Info
GPU & CPU Info reports which GPU your browser actually reaches, runs a real WebGPU compute shader to prove it works, and reads your CPU, memory and WebAssembly limits - all inside the tab.
Checking what this browser exposes...
At a glance
- Accepts
- Nothing - it reads what your own browser exposes
- Outputs
- A readable verdict plus a plain-text report you can copy into a bug report
- Where it runs
- Entirely in your browser, on your device
- What leaves your device
- Nothing - every value is read and displayed locally
- Limits
- Browsers expose a core count and a rounded memory bucket, never an exact CPU model or RAM figure
- Account
- Not required - there is no sign-up
- Price
- Free, with no watermark and no usage cap
This page reads what your browser is willing to say about the machine it's running on: which GPU it actually reaches, whether WebGPU really works or only reports that it exists, how many CPU cores it will admit to, and the WebAssembly and storage limits that decide whether a local AI model can run in a tab. It's the answer to the question you'd otherwise chase through chrome://gpu, vulkaninfo and driver documentation - and none of it leaves your device.
Why "supported" isn't the same as "working"
Most WebGPU checks test whether navigator.gpu exists. That only proves the browser has the API compiled in, not that the graphics driver beneath it can execute anything. This page goes two steps further: it requests a real device, then runs a small compute shader that doubles four numbers and verifies the result came back correct. A driver that hands out an adapter and then falls over - common with incomplete open-source drivers on Linux - is reported as broken here rather than as supported.
How to use it
- Open the page - the check runs by itself.
- Read the verdict at the top. If something's wrong, the suggested fixes underneath it are specific to what failed.
- Use "Copy report" to put the whole thing on your clipboard as plain text, for pasting into a bug report or a chat.
Frequently asked questions
Is any of this sent to a server?
No. Every value is read by JavaScript in your own tab and rendered there. Nothing is uploaded, logged, or stored - reloading the page throws it all away.
Why does it say WebGPU is supported but not working?
Because those are two different things. The page doesn't just check that navigator.gpu exists - it asks for a real GPU device and runs a small compute shader on it, then checks the numbers that come back. A half-working graphics driver will hand out an adapter and then fail that step, which is the single most common reason a browser AI demo dies with no useful error.
It found two GPUs - why?
Laptops with switchable graphics have an integrated and a discrete GPU, and the browser can return a different one depending on whether a page asks for high performance or long battery life. This page asks for both and shows you each answer, because which one you get explains most confusing WebGPU results on those machines.
What is a software fallback, and why does it matter?
It means the "GPU" is really your CPU emulating one - SwiftShader on Chrome, or llvmpipe on Linux. Everything still runs, just far slower than real hardware, and often slower than the plain CPU path would be. It's flagged separately here for that reason.
What does the max storage buffer binding number mean?
It's the largest single buffer a WebGPU shader can bind, and it's the ceiling a browser AI runtime hits first on a large model - a model whose biggest tensor exceeds it fails to load however much memory you have. Chrome's default is often 128 MB even on cards with gigabytes of VRAM.
Why does SharedArrayBuffer say no when my browser supports it?
SharedArrayBuffer is only handed to pages that are cross-origin isolated, which a site opts into with COOP and COEP headers. This page doesn't set them, so the honest answer for this page is no. The WebAssembly threads row above it tells you whether your browser could do it on a site that does.
I passed the flag and nothing changed - why?
Almost always because the browser was already running. A Chromium browser answers a second launch with "Opening in existing browser session", hands the URL to the process that's already up, and discards every flag you passed. Either quit it completely first, or launch with a separate --user-data-dir so a fresh process starts. chrome://version has a Command Line row showing what the running instance actually received.
Can it tell me my exact CPU model or how much RAM I have?
No, and no browser will. The web platform deliberately exposes only a logical core count, a rounded memory bucket, and an architecture hint - enough to size a workload, not enough to identify your machine.