WebGL inspector

See the graphics capabilities a website can query. Read renderer information, compare WebGL versions and examine supported extensions without guessing the device model.

Live browser snapshot Local analysis

See the graphics capabilities a website can query. Read renderer information, compare WebGL versions and examine supported extensions without guessing the device model.

This local snapshot loads automatically. Refresh after changing a browser setting.

RESULT PREVIEW

Measuring this browser…

The local snapshot will appear here automatically.

Graphics capability is also browser metadata

WebGL gives a webpage access to a controlled graphics API for maps, visualisations and interactive content. Applications need to know which features are supported and how large a texture can be. Those capability queries also expose characteristics of the graphics stack. A fingerprinting script can combine them with other information to distinguish configurations.

This inspector creates a WebGL context and reports its version, shading-language version, vendor and renderer strings, selected size limits and supported extensions. Where the browser exposes the debug renderer extension, the report includes its additional strings. It does not infer an exact device model from a vague renderer label or claim that software rendering proves automation.

Distinguish the browser API from the physical GPU

A renderer string may describe a translation layer, an operating-system API or a software implementation. On some platforms, the browser translates WebGL instructions into another graphics backend. The resulting label can include several names and versions. That is useful diagnostic information, but it is not equivalent to reading a trusted hardware inventory from the operating system.

The optional debug extension is commonly called WEBGL_debug_renderer_info. When available, it can expose vendor and renderer information that is more detailed than the base strings. Privacy settings can disable this extension or reduce its information. The report records unavailable fields as not exposed rather than assuming an empty device or a broken graphics card.

The tool tries a WebGL 2 context before falling back to WebGL 1. These contexts have different capabilities, so version information belongs beside the limits. A maximum texture dimension is a capability limit for this context; it does not mean the browser can safely allocate an unlimited number of textures of that size.

The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.

Use capability differences for troubleshooting

If a map or visual editor fails on one browser profile, run the inspector in the working profile and the failing profile. Compare context availability, version and extensions before focusing on the vendor label. A missing extension or a reduced limit may explain why an application selects a fallback path. The application may also have its own requirements that this report does not evaluate.

Hardware acceleration, battery-saving modes, remote desktop sessions, browser blocklists and graphics driver updates can change the selected renderer. Some systems have both integrated and discrete graphics. Which device is used can depend on operating-system policy, the browser or the workload, and a web page cannot reliably control that selection.

Record a baseline before toggling hardware acceleration. If a browser restart is required for the setting to take effect, complete that restart before measuring again. Otherwise you may compare two reports that actually describe the same process configuration. Keep the browser version with each report, because an update can change both available capabilities and the level of information exposed.

Avoid turning renderer labels into identity claims

A software renderer can appear in a legitimate virtual machine, remote session, compatibility fallback or ordinary browser with acceleration disabled. It is not sufficient evidence that a visitor is a bot. Likewise, a familiar GPU name does not prove that a request came from a trusted physical device. Client-visible information can be masked, standardised or emulated.

For privacy work, ask whether detailed graphics information is necessary for the site you are using. A browser’s supported privacy mode may suppress the debug extension while keeping WebGL available for legitimate content. Disabling all graphics features can break applications and can produce a rarer configuration. There is no universal best output for every privacy goal.

This inspector does not render a performance benchmark, stress the GPU or measure frames per second. It releases the temporary context after reading the reported fields. If you suspect a hardware fault, use appropriate operating-system diagnostics and application logs. A successful WebGL context only establishes that this browser created one under the current conditions.

When sending a renderer report to an application developer, include the failing page and an exact reproduction step. A long extension list without the observed failure is difficult to act on. Avoid replacing an actual rendering error with an assumption based only on the graphics vendor name.

Graphics fields and their limits

Reported fieldPractical meaning
VersionThe WebGL API version returned by the created context.
Unmasked rendererOptional diagnostic string; it can be disabled or reduced.
Maximum texture sizeLargest supported texture dimension, not a safe memory-allocation budget.
ExtensionsFeatures the context advertises; application support still depends on implementation.

Strengths and limitations

What this is useful for

The inspector provides concrete capability information without a stress test or external database. It is useful for comparing profiles, documenting rendering problems and checking how a privacy configuration changes exposed graphics details. The full extension list stays available in the measured-data report.

What to keep in mind

Renderer strings are not authenticated device identity. The tool does not benchmark performance, verify driver correctness or exhaustively test every advertised extension. Browser privacy controls, compatibility layers and remote sessions can change the information without indicating a fault or malicious behaviour.

Common questions

Why does the report show a software renderer?

The browser may have disabled hardware acceleration, encountered a driver blocklist, selected a compatibility path or be running in a remote or virtual environment. Check the browser’s own graphics diagnostic page and operating-system settings before interpreting the result as a device problem.

Why is the unmasked renderer unavailable?

The debug renderer extension is optional and can be suppressed for privacy. A browser can still support WebGL while refusing to expose that extra identifying information. The base renderer and supported capabilities are reported separately when the context can be created.

Is graphics information uploaded?

This inspector queries the local WebGL context and builds a report in the tab. It does not send the renderer strings or extension list to a hardware-identification service. A downloaded report includes those details, so consider what you disclose if you share it.

Does a large texture limit mean the graphics card is fast?

No. A capability ceiling is not a performance measurement. Memory pressure, bandwidth, drivers, thermal conditions and the application’s workload affect performance. A browser may advertise a large theoretical limit while failing a large allocation under actual memory pressure.

Sources and further reading

50 useful tools · ↑ ↓ to navigate · Enter to open · Esc to close