Ember Inspector: an Ember tab inside your browser developer tools

A debugging tab that only exists for Ember

Ember applications hide a lot behind a layer of abstraction. A property in a template resolves through a getter, a component holds state that is passed down through arguments, and a computed value is recomputed when you did not ask it to be. The browser's own developer tools show you the DOM, and for an Ember app that DOM is often the least interesting part of what is happening on the page.

Ember Inspector closes that gap. It adds an Ember tab to the browser's developer tools, and that tab lets you inspect Ember objects in your running application. The project is part of the Ember organisation itself, the repository sits under emberjs, and the code of conduct, issue template, changelog, release process document and development guide are all in the repository root, which is what you would expect from a project owned by the framework's core team rather than by an individual.

There is more than one way to get it, and the difference between them is not cosmetic. There is a published extension for Chrome and a published addon for Firefox, both installed with one click from the browser's own store. There is a local development build for anyone working on the inspector itself. And there is a bookmarklet, which works in any browser, including ones with no extension support at all.

The scope is narrower than a general debugging toolkit. The README describes one feature, inspecting Ember objects, and the topics list adds chrome, firefox, emberjs, javascript and hacktoberfest, which tells you this is a browser extension project with an active contributor community rather than a general developer tool. The interesting engineering is in the plumbing: how a separate panel in a separate window reaches into the JavaScript context of the page you are debugging.

Installing the published extension or a local build

The published route is one click. In Chrome the extension comes from the Chrome Web Store, and in Firefox it comes as an addon from addons.mozilla.org. Opera is handled through the same Chrome path, since the README describes visiting chrome://extensions there.

The local build is the route for anyone who wants to change the inspector, and it is also the way to test a fix before it ships. The steps are the same across Chrome, Firefox and Opera up to the loading step:

pnpm install
pnpm build

The build produces a dist directory, and the shape of that directory depends on the browser. In Chrome and in Opera you visit chrome://extensions, make sure Developer mode is checked, click Load unpacked extension, and choose the dist/chrome folder. If developer tools are already open, the README tells you to close and reopen them. In Firefox you go to about:debugging#/runtime/this-firefox, click Load Temporary Add-on, and choose the dist/firefox/manifest.json file, which is the manifest rather than a folder because Firefox loads a temporary add-on from a manifest.

The two-package structure explains the build command. The root package.json defines build as pnpm --filter ember-debug build followed by pnpm --filter ember-inspector build, so a single command builds the library that goes into your application and the panel that goes into the browser separately. The workspace uses pnpm with pnpm-workspace.yaml and a pnpm-lock.yaml at the root, and the root package is a private workspace package named ember-inspector-workspace with version 0.0.0, so the version numbers users see come from the individual packages, not from this manifest.

The toolchain requirements are explicit: Node 22 or newer and pnpm 9, with the manifest pinning [email protected] as the package manager and volta recording node 22.17.1 and the same pnpm version as the expected local toolchain.

The bookmarklet path and the local bookmarklet server

The bookmarklet is the option for environments where no extension can be installed, and it works in any browser with a bookmark bar. The whole mechanism is one line of JavaScript that injects a script into the page:

javascript: (function() { var s = document.createElement('script'); s.src = '//ember-extension.s3.amazonaws.com/dist_bookmarklet/load_inspector.js'; document.body.appendChild(s); }());

What that script does is load the inspector, and the inspector then talks to the page over window messages. The result is a separate window rather than a tab inside the existing developer tools, and the README notes the case of Internet Explorer, which opens an iframe instead of a popup because cross-origin messaging is not supported there.

For development of the bookmarklet itself, there is a local server. Running pnpm serve:bookmarklet in a terminal starts it, and the bookmarklet used in that case points at localhost instead of the hosted script:

javascript: (function() { var s = document.createElement('script'); s.src = 'http://localhost:9191/bookmarklet/load_inspector.js'; document.body.appendChild(s); }());

The README describes the expected outcome precisely: a new window opens with a URL of the form http://localhost:9191/bookmarklet/<pane-root>/index.html?inspectedWindowURL=<inspected-app-url>, running the local copy of the inspector, with the same content as the published extension but not properly styled. The missing styling is a known consequence of the bookmarklet path rather than a bug, and it is worth knowing before you conclude the panel is broken.

One security note belongs here, because the hosted bookmarklet is a remote script injected into a page you are visiting. It is the same distribution model as any CDN-hosted script, and it only makes sense for a debugging tool on pages you control.

Window messages: the contract your application can collide with

The Ember Inspector uses window messages, and the README gives that fact a section of its own, which tells you how much trouble it causes in practice.

The mechanism is the usual one for a devtools extension: the panel and the inspected page are in different contexts, so the inspector posts messages to the page and the page posts messages back. If your application also uses window.postMessage, the two message streams can be confused. The README's advice is specific: verify the sender and add checks to your event listener so that your own handler does not react to the inspector's messages.

That advice points at a real security consideration, and the README links to the MDN documentation on the security concerns of postMessage, whose subject is exactly that. A listener that accepts any message from any origin is a listener that will also accept the inspector's traffic, and the fix is the same one you would apply anyway, checking event.origin and event.source before acting on the payload. The inspector makes that requirement slightly more urgent because the messages are flowing during normal development and debugging.

The second compatibility note concerns build tooling. If your Ember app runs on Vite, the README says you may need the @embroider/legacy-inspector-support package from the Embroider project to get things working in your app. That is a specific dependency with a specific name, and it points at a broader fact about the inspector: it depends on the ember-debug side of the contract being present in the running application, and any modern bundler arrangement that changes how that library is loaded can affect whether the inspector connects at all.

The ember-debug package and the monorepo that builds both halves

The workspace contains two packages that matter to a user of the extension. The ember-inspector package is the browser extension, the panel you interact with. The ember-debug package is the code that runs inside your application, and it is what makes the inspection possible at all. The build scripts treat them as separate units throughout, with dedicated commands for building, watching and testing each one, and a combined build that runs them in sequence.

The scripts tell you how the project is developed. lint runs in parallel across the workspace, test runs lint first and then the test scripts, watch and watch-test fan out to the per-package watchers, and the build:production variant builds the inspector in its production mode. The test command for the Ember side builds ember-debug before running the inspector tests, which reflects the dependency direction between the two halves.

The release process is documented in RELEASE.md, and the root manifest depends on release-plan, a tool that the project uses to coordinate versioned releases across the workspace. A .release-plan.json file at the repository root holds the state of that plan, and RELEASE.md is the human-readable process behind it. The CHANGELOG.md records what changed in each release.

There is also a patch applied during install. The manifest lists a patchedDependencies entry for ember-cli-inject-live-reload, pointing at a patch file in the patches directory, which tells you the project carries a local modification to a dependency rather than a fork of it. That is a small but real maintenance cost: a change to that dependency upstream can conflict with the patch, and the conflict has to be resolved by whoever maintains the inspector.

For a user, none of this matters directly. For someone considering contributing, it describes a workspace with the usual moving parts of a multi-package project.

Where the inspector stops: it needs the app to play along

The clearest limitation is structural. The inspector is not a passive observer of the DOM. It reaches into the Ember runtime in your page, which means the ember-debug half has to be present in the running application, and a build that omits it, or an app that does not use Ember at all, has nothing for the panel to talk to. A browser extension that adds an Ember tab is by definition of narrow use, and that is fine, but it means the tool answers a question only Ember developers ask.

The bookmarklet path has its own limits. It needs a remote script, and it produces a window that is not properly styled, so the layout you get in daily use is not what you get from the bookmarklet. The IE case opens an iframe instead of a popup, which the README explains as a consequence of missing cross-origin messaging support, so on that browser the experience is degraded in a different way.

The Vite case is the third: some applications need an extra package from another project to make the inspector connect. Nothing in the README says how to tell whether your app is one of them, so the practical approach is to try it and read the console if the panel stays empty.

The window message collision is the limitation that will bite a mature application. Any codebase that listens for postMessage without checking the sender is already carrying a risk, and the inspector adds a second legitimate source of messages into the same channel. The README's fix is short, but it has to be applied to every listener in the application, not just the one that happened to misbehave.

Finally, an extension is a privileged position. It runs in the browser with access to the page you are debugging, and it is installed per developer and per browser profile. Teams that manage browser extensions centrally will have to allowlist it, and teams on locked-down machines may not be able to install it at all, which is the situation the bookmarklet exists for.

Licence, release cadence and who maintains the inspector

The licence is MIT, which permits use, modification and redistribution with the notice preserved, and the repository carries a LICENSE file at its root. This describes the published terms rather than legal advice. There is also a PRIVACY.md file in the repository, which is the document to read if you are asking what the extension collects.

The release record shows a project with steady output. Version 4.17.0 was published on 2026-04-24, v4.15.1-ember-inspector on 2026-02-18 and v4.15.0-ember-inspector on 2025-11-19. The suffix on the older two tags is the release-plan convention, where the package suffix identifies the package within the workspace, and the newer tag without it reflects the project moving to a scheme where the workspace version stands on its own. Either way, a release every couple of months is a normal cadence for a tool that has to keep up with Ember's own releases.

The repository is not archived, and the last push was on 2026-10-17, close to the current date. The maintenance signal comes from ownership rather than from the numbers: this is a project under the emberjs organisation, with a code of conduct, an issue template, a release process document and a development guide, which is the arrangement that tends to keep a debugging tool usable across framework upgrades.

The upgrade cost for a user is close to zero, since the extension updates itself from the store. The cost for an organisation that pins versions is that the inspector and the ember-debug package in your application have to be kept in step, and the ember-debug dependency is the one that lives in your own dependency tree.

For teams building on top of Ember internals, the DEVELOPMENT.md file and the two-package structure are the important parts, and the release-plan tooling means a change that lands in one package has to be published in the right order.

Editorial conclusion

Ember Inspector is the right tool for anyone debugging an Ember application in a browser, and for teams building tools on top of Ember internals, because it is maintained inside the Ember project and ships the ember-debug side of the contract as well. It is the wrong tool for a non-Ember application, for an environment where the extension cannot be installed, and for an app that relies heavily on window.postMessage without sender checks. Before adding it to a production build, confirm that your app includes ember-debug, and add the sender verification the README asks for so the inspector's messages cannot be confused with your own.

Frequently asked questions

Official sources

1. emberjs/ember-inspector on GitHub
2. Issues
3. License: MIT
4. README
5. Releases