M3 — WebGL

Graphics on the Web
Module 3 · Tibsfox Research · April 20, 2026

M3 — WebGL™

Section 1 — Origin

WebGL™ (Web Graphics Library) is a royalty-free, cross-platform JavaScript (JS) application programming interface (API) for rendering interactive 2D and 3D graphics within any compatible web browser, without the use of plug-ins. The API is specified and maintained by the Khronos Group through its WebGL Working Group, which was chartered in early 2009 with founding participation from Apple, Google, Mozilla, and Opera [Khronos WebGL landing — https://www.khronos.org/webgl/].

The project grew directly from a 2006 experiment by Mozilla’s Vladimir Vukicevic, who created a canvas-3D prototype demonstrating that GPU-accelerated graphics could be exposed to web content through a sandboxed, browser-controlled surface. The Khronos WebGL Working Group formalised that prototype’s API shape, aligned it with OpenGL ES 2.0 semantics, and published WebGL 1.0 as a completed specification in March 2011 [WebGL 1.0 specification — https://registry.khronos.org/webgl/specs/latest/1.0/]. WebGL’s governance has remained exclusively within Khronos; the World Wide Web Consortium (W3C) provides the HTML5 canvas element and the Document Object Model (DOM) interface through which the context is acquired, but the rendering API itself is a Khronos standard.

Unlike OpenGL® or Vulkan®, WebGL operates inside a browser security model. The specification includes explicit rules about how GPU memory is managed and zeroed, how cross-origin resources may be used, and which GPU features may be exposed without risk of fingerprinting or information-leakage attacks. This security contract is enforced at the specification level, not left to driver or application discretion.

Section 2 — Versions

Version Release year Based on Key additions
WebGL 1.0 March 2011 OpenGL ES 2.0 Vertex and fragment shaders, texture mapping, blending, canvas integration
WebGL 2.0 January 2017 OpenGL ES 3.0 (3.0.4) Transform feedback, instanced rendering, MRTs, UBOs, occlusion queries, 3D textures, integer textures, non-power-of-two textures, immutable textures, depth textures, sampler objects
WebGL 2.0 Compute (experimental) Ongoing OpenGL ES 3.1 Compute shaders exposed in WebGL context (not shipped in stable browsers as of 2026)

[WebGL 2.0 specification — https://registry.khronos.org/webgl/specs/latest/2.0/]

WebGL 1.0 achieved the 80-percent browser availability benchmark in September 2014, roughly three and a half years after its March 2011 release [Khronos WebGL blog post, Feb 9 2022 — https://www.khronos.org/webgl/]. WebGL 2.0’s journey to the same threshold was longer: it shipped first in Firefox 51 and Chrome 56 in January 2017, but did not reach universal support until February 9, 2022, when Safari 15 enabled WebGL 2.0 for all users on macOS and iOS — completing cross-browser support for the 2017 standard [Khronos WebGL landing — https://www.khronos.org/webgl/].

The Wikipedia “WebGL” article confirms the specification “provides an API for 3D graphics” via “the HTML5 canvas element” and is “accessed using Document Object Model (DOM) interfaces” [https://en.wikipedia.org/wiki/WebGL].

Section 3 — Features

3.1 The Rendering Context and Canvas Element

WebGL does not open a window or own a display surface. Instead, an application calls canvas.getContext('webgl') (WebGL 1.0) or canvas.getContext('webgl2') (WebGL 2.0) on an HTML5 <canvas> element. The returned WebGLRenderingContext or WebGL2RenderingContext object is the entry point for all subsequent drawing operations [MDN WebGL API overview — https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API]. State changes, buffer uploads, draw calls, and framebuffer reads all go through this context object.

The context holds the WebGL state machine: currently bound buffers, textures, framebuffers, programs, and viewport. This design follows OpenGL ES 2.0’s state-machine inheritance, with the browser managing context loss and restoration when the operating system (OS) reclaims the GPU on behalf of the tab.

JavaScript bindings expose each OpenGL ES function as a method of the context object. The GL types GLsizei, GLuint, GLfloat, and so on are mapped to JavaScript Number. Typed arrays (Float32Array, Uint16Array, Uint8Array) are used for buffer data uploads. Shader source code is passed as plain JavaScript strings to gl.shaderSource() and compiled at runtime via the browser’s GLSL ES front-end. No pre-compilation of shaders occurs at the WebGL specification level (though browsers may cache compiled shader programs internally).

3.2 WebGL 1.0 → 2.0 Feature Delta

WebGL 2.0 introduced a substantial set of new capabilities derived from OpenGL ES 3.0.4, all enumerated in the WebGL 2.0 specification [https://registry.khronos.org/webgl/specs/latest/2.0/]:

Transform feedback. Vertex shader outputs can be captured into buffers before the fragment shader, enabling particle systems, physics simulation, and general-purpose compute that feeds back into the pipeline without a Central Processing Unit (CPU) round-trip.

Instanced rendering. gl.drawArraysInstanced() and gl.drawElementsInstanced() allow a single draw call to issue multiple copies of the same geometry with per-instance attribute data, sharply reducing draw-call overhead for repeated objects such as vegetation, crowds, or debris fields.

Multiple render targets (MRT). A single draw call can write to up to four simultaneously bound color attachments on a framebuffer, enabling deferred shading pipelines where geometry, normal, and material buffers are all populated in one pass.

Uniform buffer objects (UBOs). Shader uniform values can be grouped into named blocks backed by GPU buffer objects. UBOs can be shared across multiple shader programs and updated with a single gl.bufferSubData() call, replacing the per-uniform upload loop common in WebGL 1.0.

Occlusion queries. gl.createQuery() and the SAMPLES_PASSED / ANY_SAMPLES_PASSED targets allow the GPU to count or test whether rasterized fragments contributed visible samples, supporting occlusion culling without CPU-side queries.

3D textures. gl.TEXTURE_3D provides volumetric texture sampling, useful for medical volume rendering, fog/density fields, and pre-computed radiance grids.

Integer and float textures. WebGL 2.0 exposes integer-format textures (R32I, R32UI, etc.) and floating-point textures (R32F, RGBA16F, RGBA32F) without extensions, enabling data-texture techniques for general-purpose computation.

Immutable textures. gl.texStorage2D() / gl.texStorage3D() allocate storage for all mip levels at once, allowing the driver to verify completeness early and use more optimal internal layouts.

Non-power-of-two textures. WebGL 1.0 restricted non-power-of-two (NPOT) textures to CLAMP_TO_EDGE wrap modes and no mipmaps. WebGL 2.0 lifts these restrictions.

Depth textures and sampler objects. Hardware percentage-closer filtering (PCF) shadows require depth textures with comparison samplers; both are core in WebGL 2.0.

3.3 Differences From OpenGL ES

WebGL is closely aligned with OpenGL ES but is not identical. The WebGL 2.0 specification, Section 5, is the normative description of every divergence. The most consequential differences:

Defined behaviour. OpenGL ES 3.0 leaves certain edge cases (reading from incomplete framebuffers, certain undefined texture formats, out-of-range attribute reads) as implementation-defined. WebGL 2.0 either defines these cases explicitly or rejects them with a gl.INVALID_OPERATION error. This is required for sandboxing: a browser cannot allow undefined GPU memory reads.

Removal of texture swizzling. OpenGL ES 3.0 allows per-texture TEXTURE_SWIZZLE_R/G/B/A parameters that remap channel reads in the shader. WebGL 2.0 removes texture swizzling entirely, because its interaction with security-sensitive read-back operations was difficult to audit.

Removal of MapBufferRange. OpenGL ES 3.0 allows CPU-side mapping of GPU buffer memory. WebGL 2.0 removes this, preventing direct CPU access to GPU-allocated memory regions that might contain cross-origin data or system memory.

ETC2/EAC compression as extensions. OpenGL ES 3.0 mandates ETC2 and EAC compressed texture formats in the core API. WebGL 2.0 moves them to optional extensions (WEBGL_compressed_texture_etc), exposed only where the hardware driver supports them natively, since not all WebGL platforms guarantee ASTC/ETC2 decode. [WebGL 2.0 specification §5 — https://registry.khronos.org/webgl/specs/latest/2.0/]

3.4 GLSL ES Shading Language in WebGL

WebGL 1.0 uses GLSL ES 1.00, and WebGL 2.0 uses GLSL ES 3.00. Shader sources must declare their version on the first line: #version 100 (WebGL 1.0) or #version 300 es (WebGL 2.0). The es suffix disambiguates from desktop GLSL [GLSL ES 3.20 specification — https://registry.khronos.org/OpenGL/specs/es/3.2/GLSL_ES_Specification_3.20.pdf]. M2 §2 “GLSL ES (Embedded Systems Shading Language) Sub-table” enumerates every GLSL ES version (1.00, 3.00, 3.10, 3.20), their host OpenGL ES / WebGL versions, and the feature additions in each — WebGL consumers should treat that table as authoritative for the shading-language side of the stack.

In WebGL 2.0’s GLSL ES 3.00, the old attribute and varying qualifiers are replaced by in and out, matching desktop GLSL 3.30. The texture2D() and textureCube() built-ins are replaced by the unified texture() function family. Integer and unsigned integer types become first-class in the shading language, enabling bitwise arithmetic.

3.5 ANGLE Translation Layer

Almost Native Graphics Layer Engine (ANGLE) is an open-source project originally created at Google. ANGLE implements OpenGL ES 2.0 and 3.0 (and by extension WebGL 1.0 and 2.0) on top of Direct3D 9, Direct3D 11, OpenGL, OpenGL ES, Metal, and Vulkan [ANGLE source — https://chromium.googlesource.com/angle/angle/]. On Windows, ANGLE translates WebGL calls to Direct3D 11 by default, because Direct3D drivers on Windows have historically been more stable and complete than OpenGL drivers from many GPU vendors.

Both Google Chrome and Mozilla Firefox use ANGLE as their WebGL backend on Windows. Safari on macOS and iOS uses Apple’s own WebKit-native Metal-backed path. Chrome on macOS uses ANGLE with a Metal backend. The practical consequence is that a WebGL application running in Chrome on Windows is compiled from GLSL ES to HLSL (High-Level Shading Language) inside ANGLE before reaching the GPU [Wikipedia WebGL — https://en.wikipedia.org/wiki/WebGL].

ANGLE’s quality and conformance testing are maintained via the Khronos WebGL conformance test suite, ensuring that the translation preserves spec-correct behaviour across all backends.

3.6 Browser Support

The following table summarises WebGL 1.0 and 2.0 support across major browsers:

Browser WebGL 1.0 WebGL 2.0 Notes
Chrome 9+ (2011) 56+ (Jan 2017) ANGLE on Windows; ANGLE/Metal on macOS; Vulkan backend in development
Firefox 4+ (2011) 51+ (Jan 2017) First browser to ship WebGL 2.0; ANGLE on Windows
Safari 8+ (2014) 15+ (Sep 2021) Enabled for all users in Safari 15; Metal backend; completed universal WebGL 2.0 support Feb 9, 2022
Edge (Chromium) 79+ (2020) 79+ (2020) Inherits Chromium ANGLE behaviour; replaced legacy EdgeHTML engine

The February 9, 2022 cross-browser milestone represents the date on which no major shipping browser lacked WebGL 2.0 support. The Khronos announcement credits Safari 15’s September 2021 general availability as the completing event, with the blog post formalising the milestone in February 2022 [Khronos WebGL — https://www.khronos.org/webgl/].

Section 4 — Ecosystem

4.1 JavaScript Libraries and Frameworks

WebGL’s low-level API requires significant boilerplate to use directly: program compilation, buffer creation, attribute binding, and uniform upload must all be managed explicitly. A rich ecosystem of higher-level libraries has grown around it:

Three.js is the most widely used WebGL wrapper, providing a scene graph, camera, material, and geometry abstractions. It targets both WebGL 1.0 and 2.0 and falls back to software rendering via a CSS2D renderer.

Babylon.js (Microsoft-sponsored) provides a full game-engine-style feature set including physics integration, asset loading, and particle systems on top of WebGL 2.0.

PixiJS targets 2D rendering with a focus on high-performance sprite batching; it uses WebGL when available and falls back to the HTML5 canvas API.

PlayCanvas and A-Frame are entity-component-system (ECS) game frameworks built on WebGL.

4.2 Debugging and Profiling

Browser developer tools include basic WebGL debugging: the Chrome DevTools and Firefox developer tools expose WebGL call logs, shader compile errors, and GPU memory usage. The standalone Spector.js browser extension captures and replays complete WebGL frame recordings, showing each draw call’s state at the time of issue — equivalent to RenderDoc for web. The Khronos WebGL conformance test suite [https://github.com/KhronosGroup] verifies specification compliance and is run against every browser release.

4.3 WebGL 2.0 Compute and Forward Reference to WebGPU

A WebGL 2.0 Compute extension specification exists at registry.khronos.org/webgl/specs/latest/2.0-compute/, extending WebGL 2.0 with OpenGL ES 3.1 compute-shader functionality including shader storage buffer objects (SSBOs) and atomic counters. As of 2026, this extension has not shipped in any major stable browser; it is superseded in practice by WebGPU.

WebGPU is a successor API developed jointly by the W3C GPU for the Web Community Group and browser engine teams, targeting Vulkan®, Metal, and Direct3D 12 natively. WebGPU shipped in Chrome 113 (May 2023) behind an origin trial and became generally available without a flag in that release. WebGPU exposes compute pipelines, storage textures, and a more explicit command-buffer model reflecting modern GPU architectures. WebGL remains in active maintenance — browser vendors continue to add compressed texture extensions, multi-draw support, and platform coverage — but WebGPU is the long-term trajectory for demanding web graphics and machine-learning inference workloads [MDN WebGL API — https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API].

4.4 Khronos Governance and Conformance

The WebGL Working Group operates under Khronos procedures. Khronos members (including Google, Apple, Mozilla, Intel, Nvidia, AMD, and others) vote on specification changes. The WebGL Conformance Test Suite (CTS) is the gate for browsers claiming WebGL conformance; passing it is required before a browser’s WebGL implementation is listed as conformant on the Khronos website [Khronos WebGL registry — https://registry.khronos.org/webgl/].

See M5 Pipeline & Patterns for the universal rendering-pipeline diagram that WebGL 1.0 / 2.0 exposes through its WebGLRenderingContext / WebGL2RenderingContext state machine, and for the cross-API terminology map aligning WebGL concepts (WebGLProgram, WebGLBuffer, WebGLFramebuffer) with their OpenGL and Vulkan equivalents.

Section 5 — Sources

Cross-references: M1 (OpenGL ES ancestry), M2 (GLSL ES shading language), M4 (Vulkan as WebGPU back-end target), M5 (pipeline stages as exposed through WebGL 2.0 rendering context).

↑ Top · GFX Home · CSP Pathway 6