How to Read a WebGL Report: GPU Names, Limits, and Extensions Explained

You open a WebGL report expecting the name of your graphics card. Instead, you find two columns, several version strings, a renderer containing the word ANGLE, and a long list of limits that begin with MAX_. One browser displays a detailed GPU description; another offers only a generic name. It is tempting to turn all of this into a simple verdict: more extensions means a better GPU, a larger texture limit means more graphics memory, or a missing model name means hardware acceleration has failed.

Those interpretations make the report seem more decisive than it is. A WebGL report describes the graphics interface available to a particular browser session. Its most useful questions are practical: can this browser create the required context, which features does that context expose, and has the environment changed since the last time an application worked?

This guide walks through the WebGL report tool in that order. You will learn how to read the fields, work through an illustrative example, and save a report that helps explain a rendering problem. You do not need to understand graphics programming to use the first few sections.

Start with the question you are trying to answer

Before looking at any numbers, decide why you opened the report. Someone troubleshooting a black canvas needs different information from someone comparing browser behavior after an update. A developer checking whether an application can use a particular feature has a third question entirely.

For a blank canvas, begin with context availability. For a browser comparison, record the renderer and the relevant capability values in both environments. For an application compatibility question, find the specific requirement in the application's documentation, then look for that requirement in the report. Reading every line without a question often produces more uncertainty than insight.

The current tool creates temporary graphics contexts, reads their information, and releases their resources. It provides separate WebGL 1 and WebGL 2 results, a filter for parameters and extensions, and a JSON download. It does not run the volumetric benchmark during this inspection. That distinction lets you capture an environment snapshot before introducing a sustained rendering workload.

It also means that a successful report is not a completed performance test. The report can establish that a context was available at capture time. To observe the behavior of the site's particular shader workload, run the Volume Shader BM Test separately and keep its result alongside the report.

Read WebGL 1 and WebGL 2 as separate results

The report checks the two APIs using separate temporary canvases. Read the availability message at the top of each column before comparing individual fields. A populated WebGL 1 column and an unavailable WebGL 2 column tell you that these two requests produced different outcomes in the current session.

They do not tell you that every web application will fail. First identify which API the application actually requests. The current Volume Shader BM Test uses WebGL 1. A WebGL 2 availability problem therefore does not, by itself, establish that this benchmark cannot run. Conversely, an application that requires WebGL 2 needs that requirement investigated even if a different WebGL 1 demonstration works.

When a context is unavailable, write down the circumstances before changing anything: browser version, whether the session uses a managed profile, whether the page is running locally or remotely, and whether other rendering pages are open. Then repeat the check after one deliberate change. A context that becomes available after restarting the browser gives you a useful observation, but it still does not identify the underlying cause on its own.

Avoid interpreting the column headings as speed categories. WebGL 2 availability is an interface capability, not a promise that a particular workload will render faster. A meaningful speed comparison would require an actual application workload and controlled conditions. The availability report serves an earlier purpose: establishing what the browser lets the application request.

Understand what the renderer name actually names

The fields most people recognize first are VENDOR and RENDERER. The tool also attempts to obtain UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL. These extra fields appear only when the corresponding debugging extension is available.

Khronos defines that extension as a way to query underlying graphics-driver vendor and renderer strings when ordinary strings may be masked. Treat those values as information supplied through the browser's graphics implementation. They are useful environment labels, and they are not an independent inventory of every graphics processor installed in the machine. Khronos: WEBGL_debug_renderer_info.

If an unmasked field is absent, preserve that absence in your notes. Do not replace it with the GPU model printed on a laptop's product page and present the replacement as a detected value. You can record the expected hardware separately, using a label such as “device specification,” while leaving the browser-reported result intact. This small habit prevents a common reporting mistake: mixing what the tool observed with what you already believe about the computer.

Why ANGLE can appear in the name

ANGLE is a graphics translation layer. Its project documentation explains that it translates OpenGL ES calls to graphics APIs available on the platform. Seeing ANGLE in a renderer string therefore describes part of the rendering path; it is not a GPU manufacturer or a separate graphics card. ANGLE project documentation.

Copy the whole renderer value when investigating a change. Reducing a long string to “NVIDIA,” “Intel,” or “Apple” can discard the detail that distinguishes two browser environments. The full text may be awkward in a chat message, which is one reason the downloaded report is more useful than a cropped screenshot.

At the same time, resist drawing a diagnosis from one unfamiliar word. A surprising renderer label is a reason to check the browser's own graphics diagnostics and the operating system's graphics settings. It is not enough evidence to declare that the GPU is broken or that a driver must be replaced. Compare the label with the observed application behavior and with a second capture under documented conditions.

Treat graphics limits as limits, not benchmark scores

Many report entries describe limits available through the context. The names look numerical and competitive, but they answer compatibility questions. A browser exposing a larger maximum does not necessarily complete your shader faster, and two devices exposing the same maximum can behave very differently under load.

The report reads values through WebGL's getParameter() interface. The parameter reference distinguishes texture sizes, viewport dimensions, attribute counts, and other values. Each value needs its own interpretation; they are not measurements in a shared unit. MDN: WebGL getParameter() reference.

The following table gives a practical reading strategy for several fields shown by the tool:

A hypothetical MAX_TEXTURE_SIZE value of 16384 does not mean the browser has 16384 megabytes of graphics memory. It also does not promise that an application can allocate every conceivable texture up to that size simultaneously. The number has a specific meaning within the API; it is not a free-memory reading.

For an everyday user, the best use of these fields is often comparison over time. Suppose a web application previously loaded an asset successfully and now rejects it. If the relevant reported limit has changed between two otherwise documented environments, that gives the developer a concrete clue. If the limit stayed the same, the investigation should continue elsewhere rather than treating the report as proof that the application ought to work.

For the site's benchmark, remember that the drawing buffer is fixed at 1024 × 1024. A large texture or viewport limit does not make the test silently switch to a larger internal rendering resolution. Record the actual benchmark conditions rather than inferring them from the maximums in this separate tool.

Shader precision describes a numeric format

The field FRAGMENT_HIGH_FLOAT_PRECISION_BITS can look like another score. The tool obtains it by asking for the precision format of high-precision floating-point values in a fragment shader. WebGL's precision query describes a shader numeric format's range and precision. MDN: getShaderPrecisionFormat().

Use this field when investigating numeric behavior or a shader compatibility requirement. It does not tell you how many frames the browser will render each second. A precision value also does not certify that every shader calculation will produce identical visible output on every device.

For example, imagine that a custom shader produces a visible band in one browser but not another. Save the shader source, record the exact steps needed to reproduce the image, and capture both WebGL reports. A precision difference may be relevant to the investigation, but the report alone cannot establish that it caused the band. The shader's own calculations and inputs still need examination.

The current report displays the queried precision-bit value when the query returns a result. It does not offer a complete numerical validation suite for custom GLSL. Keep that distinction when sharing a bug report: “the reported precision differs” is a clear observation; “the report proves this browser calculates incorrectly” requires evidence the report does not provide.

Read extensions by requirement rather than by count

The extensions section lists the extension names returned for each context. The filter makes this list easier to use: enter a relevant name or a distinctive part of it, then inspect the matching entry. Searching for an application's stated requirement is more productive than scanning an unfamiliar alphabetical list.

An extension count is a poor summary of overall browser quality. It compresses a collection of different capabilities into one total and ignores what your application actually uses. If a required extension is absent, that absence matters even when the overall list is long. If the application needs none of the additional entries, a longer list does not make its successful run more successful.

Use the extension names as evidence in a conversation with the application developer. “The WebGL 1 report did not list the extension your error message requested” is actionable. “My extension score is lower” is hard to investigate because it does not identify the feature or the failing behavior.

Also compare like with like. Keep the WebGL 1 extension list separate from the WebGL 2 list. A difference between those columns is a difference between two contexts checked by the tool, rather than a change that occurred during a single benchmark run.

Work through an illustrative report

Consider the following abbreviated example. Every value below is illustrative; it is not a measurement of a tested device or an expected result for any GPU.

WebGL 1: available
RENDERER: Generic renderer
UNMASKED_RENDERER_WEBGL: absent
MAX_TEXTURE_SIZE: 16384
FRAGMENT_HIGH_FLOAT_PRECISION_BITS: 23

WebGL 2: available
RENDERER: Generic renderer
MAX_TEXTURE_SIZE: 16384

Begin with what is established: the tool created both requested context types in this session. It received a generic renderer label, and the example does not include an unmasked renderer value. The reported texture-size limit is the same in both columns. The WebGL 1 precision query returned the value shown.

Now separate those observations from unanswered questions. The report does not establish how much graphics memory is free, how hot the device is, or how quickly it will render the volumetric scene. It does not identify the physical GPU model in this example. It also does not establish why an unmasked renderer value is missing.

Suppose the user originally opened the report because a browser game was slow. The next useful step is to reproduce that game's slowdown and record its settings. Running the shader benchmark can provide a second workload to compare, but it cannot automatically explain the game. If both workloads change after the same browser update, that is useful context to investigate, with the update and testing conditions documented.

Suppose instead that the user's only concern was the missing GPU name. A rendering workload that runs successfully helps show that the missing label and the ability to render are different questions. There is no need to change settings merely to make the report display a more satisfying product name.

Capture a report that another person can use

A report becomes much more useful when it travels with a short description of the problem. Start by opening the tool in the browser where the behavior occurs. Run the check, leave the full result available, and download the JSON report. Its capture timestamp and user-agent information help distinguish one snapshot from another.

Alongside the file, write three sentences: what you expected, what actually happened, and which steps reproduce the difference. “The canvas stays blank after selecting the default scene” gives a reviewer a starting point. “My GPU is unsupported” skips directly to an explanation that may be wrong.

If you compare another browser, create a second report and name the files clearly. Keep the first capture before updating settings or restarting the machine. Change one condition, capture again, and record the change. A pair of reports with a clear sequence is usually easier to interpret than a folder containing many unlabeled downloads.

When you include benchmark results, preserve the two kinds of evidence separately. The WebGL report records available context information; the benchmark's CSV or JSON records a run of the shader workload. The guide to comparing GPU benchmark results explains how to organize those run summaries without treating them as a per-frame trace.

Review a downloaded report before sharing it publicly. Browser and renderer information can reveal details about your device environment. The tool does not upload the generated report, but sending the file to another person is a separate action under your control. Share the details needed for the investigation and make any edits to a copy so the original capture remains available locally.

Choose the next test from the remaining uncertainty

Once you have read the report, the next step should answer a question it leaves open. If the context cannot be created, investigate browser configuration and context availability. If a required feature is missing, compare the requirement with the specific context's capabilities. If everything needed is available but rendering is slow, move to a repeatable workload measurement.

If the concern is a frame-rate ceiling, inspect browser animation cadence with the refresh-rate test and read why browser cadence can differ from monitor Hz. A GPU name and a list of graphics limits do not tell you how often the browser schedules animation callbacks.

Keep the result of each step in its own scope. A successful context check, an available extension, and a completed benchmark are three useful observations. Together they build a clearer picture of the environment, while each answers a different question. Open the WebGL report, capture the browser you actually use, and begin with the field that bears directly on the problem you want to solve.