Graphics Card Test

This page answers a plain question, what graphics card is this browser drawing with, and then shows the evidence behind the answer. It opens a WebGL context, asks for the vendor and renderer strings, and reads the limits the driver publishes: the maximum texture edge, the viewport size, the number of multisample antialiasing samples and the range of line widths it will accept.

WebGL is the reliable route because it is available almost everywhere and needs no permission. Where the browser also supports WebGPU, the page asks for a second opinion from that adapter. Where it does not, it says so rather than guessing. Nothing here requires a download, a driver utility or administrator rights.

The default WebGL parameters, VENDOR and RENDERER, are deliberately vague and often return something like WebKit. The real names arrive through an optional extension, WEBGL_debug_renderer_info, whose UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL parameters spell out the manufacturer and the model.

What those strings contain depends on the platform. On Windows they usually come wrapped in an ANGLE prefix that also names the Direct3D feature level the driver is using. On macOS you tend to see Apple or AMD and Intel names, and on Linux the Mesa driver string. Because the text is assembled by the driver, it is a reliable read on the hardware and an unreliable one on anything else.

Some browsers withhold the extension for privacy, in which case only the masked values appear. The classification chips below mark that case clearly, and the device hardware info test covers the rest of the machine.

WebGPU is the successor to WebGL, built for compute and modern rendering. A page reaches it through navigator.gpu.requestAdapter(), which returns an adapter object. That adapter carries an info record with vendor, architecture, device and description fields, plus a large set of limits such as maxTextureDimension2D and maxBufferSize.

Those fields were designed with fingerprinting in mind, so browsers keep them coarse. You will often see a short vendor token and an architecture codename such as gen-12lp with an empty device name, which is enough to tell an integrated GPU from a discrete one but not enough to pin down a model. Availability still varies by browser and platform, so the panel above reports it explicitly rather than assuming it.

Where WebGPU is present it complements WebGL: the two APIs often disagree slightly on limits, and a tracker that reads both gets a slightly sharper picture than either alone provides.

A software rasteriser is not a fault, and it is worth knowing why you might see one. SwiftShader on Chromium and llvmpipe on Firefox and Linux both mean the drawing is happening on the CPU rather than on a GPU.

Three situations produce it. Virtual machines and remote desktops often expose no 3D accelerator at all, so the browser has nothing to hand the page and falls back. Browsers also keep a blocklist of driver versions known to crash or render incorrectly, and when yours is listed the fallback is deliberate rather than accidental. Some headless and server environments do the same by configuration.

It is worth stating plainly what these strings are not. A renderer string identifies a model and a driver family, not the individual card, and not the person using it. Thousands of laptops ship with the same integrated GPU and the same driver version, and they all report the same text.

There is no browser API that returns a hardware serial, a MAC address or a machine identifier, and the graphics stack does not leak one. What it leaks is configuration. The limits table is a little sharper than the name alone, since two driver releases on the same card can differ in their extension set and maximum viewport, but it is still a description of a product rather than a tag on your device. The canvas fingerprint and the browser fingerprint work the same way.

A GPU description becomes a tracking tool only in combination. On its own it places you in a group of thousands or millions. Stacked with your screen size, fonts, timezone and language list, it helps cut that group down until it is small enough to follow you across sites without any cookie at all. That accumulation, not any single value, is the mechanism worth understanding.

If you want to reduce it, the options are the same as elsewhere: a browser that reports generic values, or reports them differently to each site, costs you nothing in performance and breaks very little. Manually spoofing one string tends to backfire, because a renderer that disagrees with the limits table underneath it is a distinctive pattern in itself. Run the fingerprint test afterwards to see whether the change actually helped.

If you came here to identify your card, the two strings near the top are the answer and the limits table is the evidence behind it. On Windows, expect an ANGLE prefix and a Direct3D feature level; on macOS, an Apple, AMD or Intel name; on Linux, a Mesa string naming the driver generation. If the name looks generic, check the blocklist case above before assuming anything is broken.

If you came to understand the privacy cost, the honest summary is that a card name on its own places you in a large group. It matters when it combines with the rest of your profile, which is what the fingerprint test measures end to end.