Browsers can draw GPU-accelerated 2D and 3D graphics into an HTML canvas element with no plugin, and WebGL is the JavaScript API behind that.
The Khronos Group maintains the standard. Its first version follows OpenGL ES 2.0, and the second is built on OpenGL ES 3.0. Browser games, web maps, data visualization tools and 3D product configurators all render through it.
It is low-level by design, and it is not a 3D engine. There is no fixed-function pipeline, so nothing reaches the screen until the developer writes a vertex shader and a fragment shader in GLSL ES (Hobart and William Smith Colleges course notes, 2013).
What Is WebGL?
The name stands for Web Graphics Library, and Khronos Group calls it a cross-platform, royalty-free standard for 3D graphics in the browser. Drawing happens in the canvas element, through JavaScript, with the GPU doing the rendering.
The Khronos WebGL Working Group looks after the spec, and the shading language is GLSL ES.
It also isn’t desktop OpenGL running inside a tab. What it follows is OpenGL ES, the embedded subset, and the Khronos specification deviates from OpenGL ES wherever interoperability or security calls for it.
Since it ships as a web application programming interface, any DOM-compatible language can call it, according to Khronos’s getting-started page.
Mozilla is where it began. Vladimir Vukicevic showed a Canvas 3D prototype in 2006, and by early 2009 Khronos had formed the WebGL Working Group, with Apple, Google, Mozilla and Opera among the first participants.
The final 1.0 specification arrived in March 2011.
It does take effort, though. Khronos’s own getting-started page warns that WebGL is low-level and that even simple things take quite a bit of code. That’s a big part of why wrapper libraries exist, and it tends to surprise people the first time they try to draw something basic.
How WebGL Renders Graphics in the Browser
See the Pen
WebGL Animation Demo with requestAnimationFrame() by Bogdan Sandu (@bogdansandu)
on CodePen.
Each frame is shared between two processors. The CPU handles control code, while shader code runs on the GPU, which works out vertex positions and pixel colors before the result lands in the canvas (TechTarget).
The CPU side is plain JavaScript that requests a context, compiles shaders, fills buffers and calls draw functions.
The render path goes in this order.
- Request a WebGL context from the canvas element.
- Compile a vertex shader and a fragment shader, then link them into one program.
- Upload vertex data to the GPU in buffers.
- Issue a draw call.
- The GPU runs the vertex shader per vertex, rasterizes triangles into fragments, runs the fragment shader per fragment and writes pixels to the framebuffer.
- The browser layers the canvas with the rest of the page.
Browsers rarely hand these calls straight to the driver. ANGLE, which the Chromium project hosts, translates OpenGL ES calls into Direct3D 9, Direct3D 11, Vulkan, desktop OpenGL or Metal, depending on the platform (ANGLE documentation).
Apple built Safari’s WebGL implementation on ANGLE too, running on top of Metal on recent iOS and macOS devices (Khronos Group, 2022).
Shaders and GLSL ES
Vertex shaders run once per vertex and output where that vertex lands on screen. Fragment shaders deal with color, and they run once per fragment.
Both are written in GLSL ES, the embedded-systems flavor of the OpenGL shading language, and the browser compiles them at runtime from source strings.
The rendering context and the canvas element
A canvas hands out one kind of context and keeps it for life. Once it holds one context type, it can’t switch to another (MDN).
Asking for “webgl2” returns a WebGL2RenderingContext, and “webgl” returns a WebGLRenderingContext. If you get null back, the browser or GPU can’t provide the context you asked for.
That null check is where every fallback starts.
WebGL 1.0 vs WebGL 2.0: What Changed
Version 1.0 follows OpenGL ES 2.0, while 2.0 is built on OpenGL ES 3.0. The 2.0 context interface implements every member of the 1.0 interface (MDN), and Packt’s Real-Time 3D Graphics with WebGL 2 calls the two versions nearly 100% backward compatible.
The 1.0 specification came out in March 2011 and gave the web its first plugin-free 3D rendering (Khronos Group). Work on 2.0 began in 2013 and finished in January 2017, with Firefox 51 and desktop Chrome 56 the first to support it (Khronos Group).
According to Khronos, the newer version added these:
- Transform feedback, which saves vertex shader output directly into a buffer
- Instanced rendering and multiple render targets
- Uniform buffer objects
- 3D textures, along with integer and floating-point textures
- Integer and bitwise arithmetic in the shading language
Several of these were optional extensions in 1.0 first. Multiple render targets, instanced drawing, and depth and floating-point textures moved into the guaranteed core, per Mozilla’s platform notes.
There is a hardware requirement too. WebGL 2.0 needs OpenGL ES 3.0-class hardware, so some systems that run 1.0 cannot run 2.0 (Khronos Group wiki).
Khronos also left a few ES 3.0 features out of the spec to avoid performance penalties on some platforms.
In practice, request webgl2 first and drop to webgl when it returns null. Unity’s current manual no longer describes a WebGL 1.0 fallback. Its Web builds support WebGL 2.0 by default, and WebGPU is an opt-in graphics API with WebGL 2 available as the fallback, per Unity’s documentation.
Which Browsers Support WebGL?
Every major browser has supported WebGL 2.0 since Safari 15 shipped it on macOS and iOS, and Khronos Group announced that milestone on February 9, 2022.
Chrome, Firefox and Edge had it earlier. Safari came last, with engineering work starting in June 2019 and Apple adopting ANGLE as the base of its implementation.
- In March 2011, the WebGL 1.0 specification was released.
- WebGL 2.0 first landed in Firefox 51 (January 2017) and desktop Chrome 56.
- Safari’s WebGL 2.0 engineering began in June 2019.
- On February 9, 2022, Khronos announced WebGL 2.0 in all major browsers.
MDN lists WebGL 2.0 as available across browsers since September 2021, five months before the Khronos announcement, and its Baseline status reached “widely available” in March 2024. Release and announcement are two different events, so the dates do not conflict.
iOS follows Safari. In most regions every browser on iOS must use the WebKit engine, so Chrome, Edge and Firefox on iOS also get WebGL 2.0, according to the Khronos WebGL wiki. In the EU, Apple has allowed approved alternative engines since iOS 17.4, so browsers there can differ.
Support still varies by machine. Khronos notes that known hardware problems or missing GPU features can stop WebGL from running, and browsers keep driver blocklists that disable it on specific older cards.
Real cross-browser compatibility for WebGL therefore depends on the user’s GPU and driver as much as on the browser name.
Feature detection beats browser sniffing here. Ask for the context and check for null.
Libraries and Engines Built on WebGL
A library makes sense when the project needs scenes, models, lights and materials. Raw WebGL is only worth it when a custom shader pipeline needs full control.
| Tool | Built for | Rendering backend |
|---|---|---|
| Three.js | General 3D scenes | WebGL 2, or WebGPU with WebGL 2 fallback |
| Babylon.js | 3D engine and games | WebGL and WebGPU |
| PlayCanvas | Game engine | WebGL 2.0, WebGPU (beta) |
| deck.gl | Large dataset visualization | WebGL, through luma.gl |
| Mapbox GL JS | Interactive vector maps | WebGL |
Three.js covers most general 3D work. Its WebGLRenderer is still maintained, and the project’s manual recommends it for pure WebGL 2 applications.
On the Babylon.js side, the team has committed to supporting both WebGL and WebGPU since version 5.0, according to its June 2024 engineering post.
PlayCanvas documentation calls WebGL 2.0 the mature backend, marks WebGPU as beta, and falls back from one to the other automatically. deck.gl sits on luma.gl, a WebGL library, and its documentation says raw WebGL knowledge is only needed for custom layers.
Raw WebGL still wins for a custom post-processing chain or an unusual shader pipeline, where a library’s scene graph just gets in the way.
What WebGL Is Used For
Browser work that leans on WebGL includes 3D games, web maps, data visualization and product configurators. TechTarget adds image-editor effects and physics simulations to the list.
Maps are the most visible example. Google’s Maps JavaScript API vector map renders with WebGL, which allows tilt up to 67.5 degrees and a full 360-degree rotation (Google Maps Platform). For the general availability release, Google moved that renderer to a WebGL 2.0 rendering context.
Data visualization is the other big one. deck.gl stacks 2D and 3D layers over a base map and attaches to Google Maps through its GoogleMapsOverlay class. It’s built for millions of points, not hundreds.
Games map onto it naturally. The rendering needs of HTML game development (mostly sprites and 3D models, with particle effects on top) line up directly with GPU draw calls, which is why engines like PlayCanvas and Babylon.js render through WebGL.
In a product configurator, the model rotates inside the canvas while swatches, prices, buttons and the like stay in ordinary page markup. Keeping controls out of the canvas keeps them accessible and easy to restyle.
Not every graphic needs a GPU. A chart with a few hundred shapes is simpler as SVG, and it stays inspectable in the DOM.
Where WebGL Falls Short
WebGL has no compute shaders, and a lost context wipes GPU resources. Draw call overhead lands on the CPU, and security rules restrict cross-origin media.
| Limit | What breaks | Workaround |
|---|---|---|
| Compute | No general-purpose GPU work | Move to WebGPU |
| Context loss | Textures and buffers invalid | Rebuild on restore event |
| Draw calls | CPU time caps frame rate | Batch, atlas, instance |
| Cross-origin media | Image refused as texture | Serve with CORS headers |
Since version 1.0.1 of the specification, cross-origin images and video can serve as textures only when CORS validates them. Media without that validation cannot be used as textures at all (Khronos Group security white paper).
Denial of service is the other documented risk. Some shader and geometry combinations take an undesirably long time to render, and Khronos named the GL_ARB_robustness extension as the countermeasure.
Context loss
A lost context invalidates every texture and buffer created before it. After the browser restores the context, the app has to reinitialize its state and recreate those resources, per MDN.
Listen for webglcontextlost and call preventDefault, or the context is never marked restorable (Khronos extension specification). Then listen for webglcontextrestored and rebuild buffers, textures and programs. To test both paths, WEBGL_lose_context has been available across browsers since April 2018.
The failure is real in production code. Mapbox GL JS shipped a changelog fix for a blank map after WebGL context loss.
Compute and performance limits
WebGL runs vertex and fragment shaders only. Compute shaders exist in WebGPU and not in WebGL (Chrome for Developers).
Batching objects into fewer, larger draw calls generally improves performance, and texture atlases let more objects share one batch (MDN WebGL best practices). Amazon’s Vega web app guidance recommends fewer than 500 draw calls per frame, a budget written for its own platform.
Most WebGL extensions depend on the client system, so query before use. Browsers also apply GPU driver bug workarounds on various platforms, according to the Khronos WebGL wiki.
Should You Choose WebGL or WebGPU?
If device reach and existing code matter most, stay on WebGL 2.0. A project that needs compute shaders, or one that will be around for years, is better off on WebGPU.
At Khronos’s WebGL and WebGPU session at SIGGRAPH on July 22, 2026, WebGPU was presented as a modern graphics API and a successor to WebGL. The same session listed a new WebGL extension and noted that browser implementations are becoming sturdier.
On November 25, 2025, web.dev announced that WebGPU is supported in Chrome, Edge, Firefox and Safari, though the details differ by platform. Firefox ships it on Windows from version 141, and on Apple silicon Macs from version 145 on macOS Tahoe 26. Version 147 extended that to all supported macOS versions. Safari ships it from version 26. Firefox on Linux, Android and Intel Macs was still in progress at the time of the announcement, and the WebGPU implementation status page (last edited in August 2026) still shows those platforms outside stable Firefox releases.
Khronos slides show coverage still growing in 2026. Chromium added Linux Intel Gen12+ support in January and a Compatibility Mode for older Android devices in February. The two sources don’t conflict, since browsers support WebGPU while devices still differ.
| Aspect | WebGL | WebGPU |
|---|---|---|
| Shader language | GLSL ES | WGSL |
| Compute shaders | Not available | First-class |
| State model | Large global state | Stateless API |
| Khronos status | Maintained, new extensions | Described as successor |
On the WebGL 2.0 side, existing GLSL ES shaders keep working, libraries still ship a dedicated WebGL renderer, and there is only one backend to debug. The downsides are the missing compute shaders and higher driver overhead than WebGPU, according to PlayCanvas documentation.
WebGPU brings compute shaders, reduced driver overhead and a stateless design. Against that, custom shaders need a WGSL rewrite, and platform coverage is still filling in.
Speed is not automatic either. ICS Media reported that as of Three.js r176 in May 2025, WebGLRenderer could sometimes run faster than WebGPURenderer.
Shader code is the real migration cost. WebGPU uses WGSL, and Three.js bridges the gap with TSL, a node-based shading language its WebGPURenderer supports.
For an existing WebGL codebase, staying put makes sense unless a feature forces the move. Anything that needs GPU compute (particles, physics or ML inference) points to WebGPU. A new, long-lived project on a library should use its WebGPU renderer, with the WebGL 2 fallback on.
WebGL FAQ
Is WebGL the same as OpenGL?
Not quite. WebGL follows OpenGL ES, the embedded subset, and the specification has a dedicated section listing every difference from OpenGL ES.
Several of those differences exist for interoperability and security reasons.
Does WebGL cost anything to use?
Nothing. The standard is royalty-free, so the API itself carries no license fee.
Libraries are another story. The PlayCanvas Engine is MIT-licensed, but Mapbox GL JS from version 2.0 requires an active Mapbox account under the Mapbox Terms of Service.
Is WebGL safe to leave enabled?
Largely yes. Khronos defines security-relevant behavior that OpenGL ES leaves undefined, and the WebGL conformance suite tests those safeguards.
Denial of service from heavy shaders remains the documented risk.
How does WebGL differ from Canvas 2D?
WebGL draws through GPU shaders. The 2D context has a simpler drawing API, and O’Reilly’s HTML5 Canvas, 2nd Edition notes that WebGL is harder to learn.
For flat drawing the 2D context is enough. WebGL starts to pay off once the scene is 3D or too heavy for the CPU.
Does WebGL run on Android phones?
Yes. Khronos reports good WebGL 1.0 support on both desktop and mobile in the major browsers.
WebGL 2.0 shipped in Chrome for Android 58 and Firefox for Android 51, according to the web-platform-dx web-features data.
How can you check whether WebGL works in your browser?
Open get.webgl.org and look for the spinning cube.
For hardware status in Chrome, open chrome://gpu and read the WebGL line under Graphics Feature Status. Hardware accelerated means the GPU is doing the rendering.
How do you turn WebGL on when it is disabled?
Start with graphics acceleration. In Chrome, open chrome://settings/system, enable Use graphics acceleration when available and relaunch.
Edge keeps the same switch at edge://settings/system, labeled Use hardware acceleration when available. In Firefox, open about:config and set webgl.disabled to false.
Where to Start With WebGL
Start WebGL work from a library renderer, not raw API calls, and add custom shaders last. That order keeps the costly rewrite, GLSL ES to WGSL, as small as possible if a project moves to WebGPU later.
Pick a library renderer with its WebGL 2 backend enabled, and deal with context creation failure and context loss before adding any features. Custom GLSL ES shaders can wait until the scene runs.
What you give up is control. A library renderer decides how draw calls get batched, so tuning that behavior later means reading the library’s source instead of owning the loop.
The recommendation holds for the device mix verified in October 2026. It changes once every target device ships a working WebGPU path, at which point the library’s WebGPU renderer becomes the primary choice and the WebGL 2 backend becomes the fallback.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- Figma Keyboard Shortcuts That Will 10x Your Speed - October 25, 2026
- What is Backend in Web Development? - September 13, 2026
- What is Frontend Development? - September 11, 2026
