A-Frame Inspector: a visual editor injected into any A-Frame scene

An injected panel, not a separate application

The A-Frame Inspector is a visual inspector tool for A-Frame scenes, and the mechanism is the interesting part. A-Frame comes with a keyboard shortcut to inject the inspector: open any A-Frame scene running at least A-Frame v0.3.0 and press ctrl, alt and i to inject the inspector, just like you would use a DOM inspector.

So there is no separate editor to launch, no project to open and no connection to set up. The inspector appears over the running scene in the same browser tab, and it operates on the scene that is already there. The scene itself is unchanged, which means the thing you are inspecting is exactly the thing that will ship.

The runtime dependency is A-Frame itself, and the documentation and guide live in the A-Frame documentation under the visual inspector and dev tools section, with a separate examples site. The companion tool mentioned in the README is A-Frame Watcher, a server that syncs changes to HTML files, which tells you how the workflow is meant to close: you edit in the inspector, the watcher writes the change back into the HTML, and the next reload shows the same thing.

The repository layout matches a tool that is shipped as a bundle rather than as a library. There is a dist/ directory at the top level, a src/ directory with the source, webpack.config.js and a babel configuration, a jest setup, eslint and stylelint configuration, an assets/ directory, an examples/ directory, and a husky setup for commit hooks. The examples directory includes 360video.html, colors.html, controllers.html, embedded.html, embedded-zoom.html, empty.html, supercraft.html and an index.html, which is the set of scenes the tool is exercised against.

The inspector component decides which build gets loaded

The inspector is attached to a scene through the inspector component, and by default it is already set on the scene. If you want a specific build of the inspector injected, you pass a URL, and the README gives the local development case first:

<a-scene inspector="url: http://localhost:3333/dist/aframe-inspector.js">
  <!-- Scene... -->
</a-scene>

And then the master branch of the inspector, for trying unreleased changes against a real scene:

<a-scene inspector="url: https://cdn.jsdelivr.net/gh/aframevr/aframe-inspector@master/dist/aframe-inspector.min.js">
</a-scene>

The url property is the whole extension point, and it is a simple one: the component takes a URL, the page injects that script instead of the default. The two examples cover the two situations you actually have, a build running on your own machine during development, and the latest published code from a CDN when you want to check whether a change has landed.

The default being already set on the scene is worth noting, because it means the tool is available without any markup changes, and the configuration is only needed when you want a different build. The debugging use is called out explicitly in the README, which is a sign that the workflow of developing the inspector against a live scene is the intended one.

React and three.js as the panel implementation

The dependency list in the package manifest describes the panel precisely, and it is a small, modern stack.

The UI is React 18 with react-dom, react-select for the dropdown controls, clsx for conditional class names, prop-types for the component contracts, and the free solid SVG icons from Font Awesome. lodash.debounce is there for input handling, and clipboard-copy for copying values out of the panel. The 3D side is three at version 0.182.0, which is the renderer the inspector uses to draw the scene it is editing and to visualise gizmos.

The build is webpack with a dev server, and the package scripts show the full pipeline. The build runs webpack with progress output, dist produces both a max and a minified bundle, with the minified one produced by setting MINIFY=true through cross-env, and the main field points at dist/aframe-inspector.min.js. The GitHub Pages deploy path runs a preghpages step that builds the distribution, clears and recreates a gh-pages directory, copies assets, dist, examples and index.html into it, and rewrites the localhost URL in the examples index to a relative path with sed.

Tests run through jest with a BABEL_ENV of testing, in watch mode by default and with a separate test:ci script for the non-interactive run. Linting is split into an eslint pass over src/ and a stylelint pass over the styles, and prettier formats the source.

Camera position follows the scene since A-Frame 1.7.0

Since A-Frame 1.7.0, the inspector perspective camera position is kept in sync with the A-Frame active camera. The effect is that you can move around the scene, toggle the inspector, and you will be at the same position when it opens.

That is a small feature with a disproportionate effect on how the tool feels. Without it, toggling the inspector moved you back to a default viewpoint, and you had to re-navigate to where you were working every time you opened and closed the panel. With it, the inspector is a layer over your current view rather than a separate mode.

The behaviour can be turned off by defining a global variable before any script tag:

<script>
  window.AFRAME_INSPECTOR_CONFIG = { copyCameraPosition: false };
</script>

The same global object carries the second configuration option. If you run the A-Frame Watcher from a different host or port, you can set AFRAME_INSPECTOR_CONFIG to specify a custom endpoint:

<script>
  window.AFRAME_INSPECTOR_CONFIG = {saveEndpoint: "http://my-custom-host.org:1234/save"};
</script>

The saveEndpoint option is what connects the inspector back to the watcher, and it is the piece that makes the round trip work when the watcher is not on the default host.

The textures modal reaches out to a CDN by default

One dependency of the inspector is not obvious from the outside. The textures modal is using the sample-assets images.json at aframe.io to get the available textures, and the repository for those assets is a separate aframevr/sample-assets repository.

If you want to self-host that directory, the README gives a two-step procedure. You clone the sample-assets repository into the examples directory:

cd examples
git clone [email protected]:aframevr/sample-assets.git

And then you edit index.html and define a global variable before any script tag:

<script>window.AFRAME_SAMPLE_ASSETS_ROOT = "./sample-assets/";</script>

This matters for two kinds of deployment. An offline demo, a workshop, or a VR session on a venue network will find the textures modal empty or slow if the CDN is unreachable, and the two commands fix that. A site that does not want a third-party request on every scene load has the same option.

The reason it is worth mentioning in an evaluation is that this is a runtime network dependency in a tool people assume is entirely local. Everything else the inspector does happens in the page, and this one panel reaches out to a remote JSON file.

For local development of the inspector itself, the README's steps are a clone, an install and a start, and then you navigate to the examples page on localhost:3333:

git clone [email protected]:aframevr/aframe-inspector.git
cd aframe-inspector
npm install
npm start

Where the inspector falls short

The first limitation is the release history. The recent releases are v1.4.1, whose tag name is v1.4.0, from 2023-01-06, v0.6.0 from 2017-09-20 and v0.5.3 from 2017-06-05. The version in the package manifest is 1.8.0, which does not match any of those tags, so the published npm version and the release list are not the same thing. The last push to the repository was on 2026-07-14 and the repository is not archived, so work continues, but there is no tag after January 2023 and the numbering is inconsistent enough that you should check which artefact you are actually getting.

The second limitation is the scope of the tool. The inspector is for inspecting and tweaking an existing scene. It is not a scene authoring environment with a hierarchy view, prefab system or asset pipeline, and the companion tool it points at, A-Frame Watcher, is described only as a server to sync changes to HTML files. A large project still keeps its A-Frame content in HTML, and the inspector is a way to manipulate that content and write it back, not a replacement for the source format.

The third limitation is the injection model. The panel lives inside the page, so anything it shows is only as accurate as the state A-Frame exposes, and the keyboard shortcut has to be pressed in a page that has the inspector component set, which the README says is the default but which is a per-scene setting. On a page where the component has been removed, there is no inspector, and the same applies to a scene running in a WebGL context where the browser has blocked the injected script.

The real alternative is a separate 3D editor such as Blender, with the A-Frame scene exported or authored as glTF and brought in. The difference in approach is fundamental. A separate editor gives you modelling, materials, rigging and a scene graph, and produces a static asset that a runtime then loads. The inspector works on the live scene graph that A-Frame has already built, so what you see is what the runtime is doing, including component behaviour and dynamic updates that a static asset could never show. For tuning an existing A-Frame scene, the inspector answers questions a static asset pipeline cannot, and for authoring new content it is not the tool.

Editorial conclusion

Adopt A-Frame Inspector if you build A-Frame scenes and want to author positions, rotations and component properties by clicking in the scene rather than by editing HTML and reloading. Do not adopt it as a full scene editor, since it is an inspector for an existing scene, and do not expect it to work outside a browser context, since it depends on the A-Frame runtime injecting itself. Before you rely on it, point the inspector component at a local build with the url property, since the default is the published bundle, and check that the keyboard shortcut does not clash with the browser or the operating system in the environment you are testing in.

Frequently asked questions

Official sources

1. aframevr/aframe-inspector on GitHub
2. License: MIT
3. Project website
4. README
5. Releases