What ANGLE means in your WebGL renderer string

ANGLE in a WebGL renderer string is the translation layer Chrome draws WebGL through. ANGLE stands for Almost Native Graphics Layer Engine: it takes the OpenGL ES calls WebGL makes and turns them into Direct3D on Windows, Metal on a Mac, and OpenGL or Vulkan elsewhere. The renderer string names that backend, so it tells a site which operating system you run, separately from what the User-Agent claims.

What is ANGLE in a WebGL renderer, exactly

WebGL is a browser version of OpenGL ES. Most operating systems do not offer OpenGL ES to desktop applications, and Windows in particular never shipped dependable OpenGL drivers for every card. ANGLE is Google's answer: an implementation of OpenGL ES written on top of whichever native API the machine does have. Chrome uses it for WebGL on every desktop platform, and ANGLE's shader translator also checks the shaders a page sends, so one set of rules decides what a WebGL program may do.

When a page asks for the renderer with getParameter(UNMASKED_RENDERER_WEBGL), from the WEBGL_debug_renderer_info extension, ANGLE builds the answer from three things: its own name, what the driver says the card is, and the backend it chose. The vendor string beside it reads Google Inc. (NVIDIA) or similar, because ANGLE is a Google project wrapping somebody else's hardware.

How it works: Machines that exist

How to read the renderer string, platform by platform

These are real strings, as browsers report them, taken from the table our device catalogue is checked against.

On Windows, ANGLE translates to Direct3D 11:

ANGLE (Intel, Intel(R) UHD Graphics 620 (0x00005917) Direct3D11 vs_5_0 ps_5_0, D3D11)

Direct3D11 is the backend, and vs_5_0 ps_5_0 are the vertex and pixel shader models a Direct3D 11 card exposes. The bracketed hex is the PCI device id, which ANGLE reads from the driver. Very old Windows machines report Direct3D 9 instead, with Direct3D9Ex vs_3_0 ps_3_0 and the driver's DLL name at the end.

On a Mac with Apple silicon, ANGLE translates to Metal:

ANGLE (Apple, ANGLE Metal Renderer: Apple M2, Unspecified Version)

There is no device id and no shader model, only the chip's name. Some older Intel Macs still report ANGLE's OpenGL backend, in a shape only macOS produces: ANGLE (Intel Inc., Intel Iris Pro OpenGL Engine, OpenGL 4.1). OpenGL 4.1 is where Apple froze its OpenGL support, and "OpenGL Engine" is how Apple's drivers name themselves.

On Linux, ANGLE runs over the system's OpenGL, and the string carries the driver's own spelling:

ANGLE (NVIDIA Corporation, NVIDIA GeForce RTX 3090/PCIe/SSE2, OpenGL 4.5.0)
ANGLE (AMD, AMD Radeon Graphics (radeonsi renoir ACO), OpenGL 4.6)

NVIDIA Corporation with /PCIe/SSE2 is the proprietary NVIDIA driver; radeonsi and ACO or an LLVM version are Mesa, the open-source driver stack. Android phones report OpenGL ES 3.2 with a mobile GPU such as Adreno or Mali, and some Linux machines end in OpenGL ES 3.2 too, so that last suffix alone does not separate the two.

Why the backend announces the operating system

Direct3D11 exists on Windows and nowhere else. ANGLE Metal Renderer exists on macOS and nowhere else. A Mesa build string exists on Linux. None of this comes from the User-Agent or from navigator.platform; it comes from the graphics stack, so it is a second, independent statement of the OS.

That makes it the first thing a consistency check compares. A browser that says Windows in its User-Agent and Metal in its renderer has contradicted itself in two calls, and no ordinary machine produces that pair. The same goes for subtler mismatches: a Direct3D 11 string with no device id is a shape no driver emits, and when we checked our own hand-typed Windows rows, 41 of 45 were missing that id.

The renderer is also not the only place the backend shows. Each backend reports its own capability limits and shader precisions, and Pixelscan alone reads sixty WebGL fields. Change the renderer text and leave those alone, and the string disagrees with the numbers beside it. WebGPU is a third route: navigator.gpu describes the adapter directly, and its vendor has to match the vendor inside the WebGL string. That pair is a row in our detection catalogue.

A few strings mean no GPU at all. Microsoft Basic Render Driver on Windows and SwiftShader, Chrome's own fallback on any platform, are software rasterisers. They are honest strings from virtual machines, remote desktops and headless bots, which is a large share of automated traffic, and a profile that reports one looks like that population.

How Mosaic keeps the renderer and the platform in agreement

Mosaic draws each profile's GPU from a catalogue of real machines, together with its screen, CPU threads and memory, so the renderer string belongs to the same machine as everything else the profile claims. Every renderer the catalogue can emit has to appear in a table of strings observed on real browsers, and our build refuses any row that is not there. The value is set inside Tesseract Chrome, our own Chromium, so every page, frame and worker reads the same string, and no script layered on top can disagree with it. (One more trap: the renderer can come back empty on a fresh WebGL context; the null UNMASKED_RENDERER_WEBGL post has the cause.) How the machines are chosen is on the real fingerprints page.