ShaderEditorExtension: live editing GLSL in Chrome DevTools

A DevTools panel that patches WebGL before the page does

ShaderEditorExtension is a Chrome DevTools extension to help you edit shaders live in the browser, and the README says it is very much based on the Firefox DevTools Shader Editor. It comes with a video showing it in action, and a write-up on creating a plug and play live WebGL shader editor by the same author, who also wrote the extension's own Chrome Store listing text.

The mechanism is instrumentation rather than a debugger protocol. The README is explicit about the requirement: the extension needs to instrument WebGLRenderingContext, and if you open DevTools after the page has loaded you have to hit the Reload button, whereas if the extension was already running it automatically instruments the page.

That single sentence explains most of the limitations people hit with extensions of this kind. The extension has to get in front of the page's own WebGL calls before they happen, and the only way to guarantee that is for the extension to be running first. A page that creates its WebGL context during load, which is most of them, will not be seen at all until a reload.

The project also has a twin, the Web Audio API Editor Extension for Google Chrome, which is the same idea applied to the Web Audio API.

The primary language is JavaScript, the licence is MIT with the copyright held by Jaume Sanchez Elias, the default branch is master, and the last push was on 2026-10-17. The repository has no GitHub releases, so the Chrome Store listing is the distribution channel and the source repository is where the work happens.

Installing from the Chrome Store or from disk

There are two installation routes and the second is the one a developer actually wants.

From the Chrome Store, the README simply says to follow the link and install the extension from the Chrome Store. The listing is linked twice, once in the install section and once as a badge near the top of the page.

Loading it from disk is the route for anyone who wants to modify it, and the steps are spelled out. Check out the repo, open Chrome's Extensions page, which the README gives as Settings / More tools / Extensions, enable Developer Mode, click on Load unpacked extension, and select the src folder in the checked out project.

The point to notice is that the folder you select is src, not the repository root. The top level of the repository holds a README, a CHANGELOG, a LICENSE, an about directory for the Store assets and a src directory, and the extension manifest and code live under src.

There is also a third option for people who want to distribute it rather than hack on it. The README says you can pack the extension yourself and load it by dropping the .crx file in the Extensions page. That is the path for a shared build inside a team, where several people need the same patched version and pulling from the Store is not an option.

The practical difference between the Store version and a disk load is that the disk version is the one you can edit, and a developer reading the TO-DO list, which invites forks, pull requests and code critiques, is expected to be doing the second.

The workflow once the Shader Editor tab is open

The usage section is a sequence, and it reads like the actual session.

You browse to a page with WebGL content, and the README offers three places to find one, threejs.org, chromeexperiments.com/webgl and webgl.com. You open DevTools and select the Shader Editor tab. The extension needs to instrument WebGLRenderingContext, and if you opened DevTools after the page had loaded you hit the Reload button.

Then the panel does its work. If there are calls to .createProgram, the UI will show a list, and selecting a program shows its vertex shader and fragment shader. The Pretty Print icon makes the code more readable, the fullscreen button makes the code editor bigger, and the Star icon applies the GLSL Optimiser.

The visibility controls are on the shader list itself. The check mark icon next to each shader's name toggles its visibility, and the Eye icon disables shader highlighting.

The Textures tab handles the other half of the debugging. Clicking a texture opens a File Dialog to use another texture, and you can also drag and drop a file into the texture. That is the feature that makes this more than a source viewer, because swapping a texture at runtime is how you answer a question like whether a lighting result is wrong because the normal map is wrong.

The Setting tab has a performance escape hatch: enable or disable texture monitoring and shader highlighting, for performance reasons. That is a real acknowledgement that the instrumentation costs something on a heavy page, and that the extension's own features can be the reason a page feels slow.

The open issue list is the honest documentation

The TO-DO section of the README is more informative about the current state than the feature list, and the done items are struck through.

The completed ones are detecting when the page is reloaded or changed, which was issue 1, and highlighting shaders when hovering over a list item, which was issue 3. Both of those map directly to features in the usage section, the reload detection and the highlighting toggle.

The open ones are more revealing. There is an issue to check why some pages don't load, with http://david.li/flow/ named as an example. There is an issue to figure out why it doesn't .postMessage the first time it's injected. There is an issue to figure out why it doesn't work on Android over remote debugging. And there is an issue to check why some pages don't load, which points at the fact that the extension's coverage depends on the page cooperating with the instrumentation.

The .postMessage problem is the interesting one. The extension and the page are in different JavaScript contexts, the DevTools panel and the inspected page, and the bridge between them is a postMessage. If the first injection does not post a message, the panel has nothing to list, which is the failure mode behind a blank panel on a page that clearly has WebGL content.

The Android one is a separate class of problem again, because remote debugging on Android means the extension is not running in the same browser process at all, so the instrumentation strategy that works on a desktop Chrome does not transfer.

There is also a list of nice to have items. Save to disk is marked as not possible for now with the DevTools API, which is an interesting constraint: a DevTools extension has no filesystem access, so the editor cannot write the shader back to your project, and the edited source has to be copied out by hand. Adding uniform tracking to display values fed to the shader is on the list, and the integration of the GLSL Optimiser by aras-p and zz85 is struck through and marked as added, with a link to the commit.

For a tool that has been around since 2015, an open issue list of this shape is a reasonable sign of a maintained project with a known edge.

What it does not do, and what to use instead

Two boundaries are worth stating, one of which is a hard limitation of the platform.

The first is that there is no way to save the edited shader back to disk, and the README attributes this to the DevTools API rather than to an omission. So the workflow ends with the developer copying the modified source out of the panel and pasting it into the project. For a shader that takes ten iterations to get right, that is a real friction, and it is the reason the live editing experience feels incomplete even when the live editing itself works well.

The second is that this is a Chrome DevTools extension, so it is bound to the Chrome extension model, to the DevTools panel API, and to the WebGL API as Chrome exposes it. A Firefox user gets the original the README is based on, the Firefox DevTools Shader Editor, which is the reference implementation here rather than a port of it.

The realistic alternative approaches the same problem differently. The first is to build the shader into the page and reload, which is what most WebGL development does, with a build step and a source file as the source of truth. The second is to use the Firefox DevTools Shader Editor directly, which is the tool this one is modelled on. The third is to use a purpose built WebGL debugging tool or a framework's own overlay, which for three.js means its own shader inspection facilities rather than patching the context.

The difference in approach is worth naming. Patching WebGLRenderingContext at the page level is a different thing from a native browser feature. A native inspector can know more about the pipeline because it is inside the browser. A page level extension has to intercept the API calls and reconstruct the state, which is why this one needs .createProgram calls to be visible, why it needs the page to be instrumented before load, and why some pages simply do not cooperate.

The extension is therefore at its best in a narrow and useful place, which is a page you control, that you can reload, that uses ordinary WebGL calls, and where you want to iterate on shader source and swap textures without a rebuild. That is a real and common situation, and the tool handles it.

Editorial conclusion

ShaderEditorExtension fits a web graphics developer who needs to see the actual shader source a page compiled and change it without a rebuild, and it does not fit a Chrome user on a page the extension cannot instrument, since the open issue list names pages that fail to load and a problem with Android over remote debugging. Before relying on it, load the extension from disk in Developer Mode and confirm the Shader Editor tab appears on a page you control, because the instrumentation only takes effect if the extension was already running when the page loaded, otherwise you have to hit Reload.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. spite/ShaderEditorExtension on GitHub