alpinejs-devtools: a browser inspector for Alpine.js components
Chrome/Firefox DevTools extension for debugging Alpine.js applications.
At a glance
- What is it?
- The Alpine.js devtools extension gives you a panel for inspecting and editing component state, hovering to highlight an element in the page, and reading component data from the console. Alpine has no named components, so the extension infers a name from id, name, aria-label, x-data, role or tagName, and part of the feature set now sits behind a paid early access tier.
- Who is it for?
- alpinejs-devtools suits an Alpine developer who has outgrown console.log debugging and wants to see and edit the state of a component tree, especially with the free features that cover state inspection, hover highlighting and console globals. It does not suit you if you need the store inspector, the warnings tab or the time travel debugging of $data, since those are in the paid early access tier, and the free extension does not cover them.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Identifying a component when Alpine gives you no names
Alpine.js devtools is a simple extension to help you debug Alpine.js components easily, and the extension is heavily inspired by Vue devtools but customized for a unique Alpine.js developer experience.
The hard part with Alpine is that there are no named components. Alpine's whole design is that you put attributes on elements, and x-data holds the state, and there is no component registry to inspect. Vue devtools can show you a tree of components with names because Vue has components. Alpine has markup.
So the extension guesses. By default it will attempt to identify component names from a list of attributes, in order: id, name, aria-label, x-data which gives the function name, role, and finally the tagName. The order is a sensible priority order, since an explicit id is the most deliberate thing a developer can give an element, and the tagName is the last resort.
You can override the guess with either x-title or x-id. That matters when the heuristic picks badly, and it is the mechanism a developer reaches for when a page has many elements with the same role.
The extension is available on the Chrome Web Store and as a Mozilla add-on, with the project homepage at alpinedevtools.com. The licence is MIT.
The free extension and the paid early access split
There is a notice at the top of the README that changes how you should read the rest of it, because the project now runs two tiers.
Due to Chrome's Manifest v3 rollout, the extension had to be rewritten, and as part of that a Paid Early Access Program has been launched. The free extension includes component state inspection and editing, more reliable state updates and sync, highlighting a component in the page on hover, component data in console globals, high performance on nested data objects which was tested on roughly ten thousand data properties, and component filtering.
The early access tier adds store state viewing and editing, store data in console globals, a warnings tab with Alpine v3 support, jump to root element and scroll element into view, and time travel debugging of $data.
What that split tells you about the priorities is useful. The free tier is about component state, which is the thing you need most of the time, and the performance note is a real engineering claim, since an Alpine component holding ten thousand properties in its data object is not unusual for a table driven interface, and a naive inspector that walks the object on every render would be unusable.
The paid features are about history and diagnosis. Time travel debugging of $data means being able to step back through state changes, which is a substantial piece of machinery rather than a display toggle, and the warnings tab is a static analysis of the page rather than a live view of it.
One practical note for Chrome users. The extension will not work with local files unless you configure it to be allowed Access to File URLs. The steps are to open chrome settings, go to the extensions tab, choose Alpine.js devtools and press details, then enable Allow access to file URLs.
The devtools simulator, and why it exists
The most interesting engineering decision in the repository is the devtools simulator.
A devtools simulator is provided in order to run tests and have an easier development workflow. The key point is that when using the simulator all Chrome and Firefox devtools and extension APIs are faked, so it is useful if you are working on the Extension Backend, which runs in the end user's window and lives at packages/shell-chrome/src/backend.js, or on the Alpine.js app which runs in the devtools panel, with the entrypoint at packages/shell-chrome/src/devtools/app.js.
That split of processes is the reason the simulator exists at all. A browser extension has two halves running in different windows with different privileges, and the panel half talks to the page half through a devtools API that only exists inside a real browser. Faking that API lets you develop and test the panel in a normal browser tab with a sample Alpine app beside it.
Running it is straightforward. Clone the repo, run pnpm install, run pnpm start, and open the local server on port 8080. The default port is 8080 and you can override it with the PORT environment variable, for example PORT=5000 pnpm start starts the simulator on port 5000. What you see is a page with the sample Alpine.js app, example.html in packages/simulator, running in the top half of the screen and the devtools simulator, dev.js, running in the bottom half.
The development prerequisites are Node ^24.x and pnpm ^10.x, and the package scripts show the workspace shape. The start script delegates to the browser-extension package, the build script sets VITE_MAINLINE_PUBLISH=true before building, and the format script runs Prettier over the packages and lib directories.
What the repository layout says about how the extension is built
The top level of the repository is a pnpm workspace with the extension itself under packages/.
The root holds package.json, pnpm-lock.yaml, pnpm-workspace.yaml, a.prettierrc.js and a.prettierignore, a.editorconfig, a.husky/ directory, a lint-staged.config.js, a.github/ directory, and a docs/ directory holding the screenshots the README uses. There are also two files worth reading before you install: FEATURES.md, which is the feature list, and AGENTS.md, which is instructions for coding agents working in the repository.
The package layout inside packages/ is what makes the simulator story work. There is a simulator package holding the example.html sample app and dev.js, and the Chrome shell package holds the backend that runs in the end user's window and the devtools panel app with its entrypoint. The scripts confirm the shell package is the build unit, since the start and build scripts both delegate with pnpm --filter=browser-extension.
The version recorded in the root package.json is 1.3.0, and the package is marked private, which is normal for a workspace root that is never published itself. The published artefacts are the extension bundles, not the workspace.
One dependency detail is easy to miss and tells you what the tests run against. The devDependencies include alpinejs at 2.8.2, which is the Alpine version the development environment and the simulator sample app use. The extension supports Alpine v3, as the warnings tab description notes, but the pinned development dependency is still on the 2.x line, so the sample environment and the supported range are not identical.
The release history shows v2.7.3 on 2026-01-23, v2.7.4 on 2026-01-30 and v2.8.0 on 2026-07-15, with the last push on 2026-10-21, and the repository is not archived.
Two levels of tests, and the browser-specific build steps
There are two levels of tests in the project, and the split tells you what is worth testing where.
The unit tests live in ./tests, written and run with node:test, and the command to run them is pnpm test. The end-to-end tests run against the devtools simulator, in ./cypress, using Cypress, with pnpm cy:run to run them and pnpm cy:open to open the Cypress UI. The note is important: in order to run any Cypress tests you need the simulator running.
So the unit tests run with the Node built-in test runner and no extra dependency, while the end-to-end tests need the fake devtools environment running. That is a sensible split, because a good chunk of the extension's logic is pure transformation of Alpine data, and that can be tested without a browser at all.
Building for a real browser is also documented separately for each. For Chrome, clone the repo, run pnpm install, run pnpm build:dev or pnpm build for a production build, load the unpacked extension inside the dist/chrome directory, then open any HTML file that imports Alpine.js and inspect with Chrome DevTools, where an Alpine.js panel should be available.
For Firefox, follow the same development instructions, go to about:debugging#/runtime/this-firefox in Firefox, make sure you are on the This Firefox tab in the left side nav, click Load Temporary Add-on, open any of the files in the built extension folder, then open an HTML file that imports Alpine.js and inspect with Firefox DevTools.
The packaging scripts in package.json show how the two stores are served. There is a separate early-access and mainline build path, since the two tiers are different builds, and the package script builds Chrome and Firefox with web-ext and then archives the extension source with git archive.
Formatting is handled by Prettier with the config at .prettierrc.js, on push a GitHub Action auto-formats your changes, and on commit a husky and lint-staged hook runs and auto-formats your changes unless you disable pre-commit hooks.
Editorial conclusion
alpinejs-devtools suits an Alpine developer who has outgrown console.log debugging and wants to see and edit the state of a component tree, especially with the free features that cover state inspection, hover highlighting and console globals. It does not suit you if you need the store inspector, the warnings tab or the time travel debugging of $data, since those are in the paid early access tier, and the free extension does not cover them. Before you rely on it, check the FEATURES.md file in the repository for the current split between free and paid features, and note that on Chrome you have to allow access to file URLs if you develop against local HTML files.
Frequently asked questions
How does alpinejs-devtools name a component when Alpine has no named components?
It tries a list of attributes in order: id, name, aria-label, x-data which yields the function name, role, and finally the tagName. You can override the guess with either x-title or x-id.
What is included in the free Alpine.js devtools extension?
Component state inspection and editing, more reliable state updates and sync, highlighting a component in the page on hover, component data in console globals, high performance on nested data objects tested on roughly ten thousand properties, and component filtering.
How do I run the Alpine.js devtools simulator?
Run pnpm install, then pnpm start, and open http://locahost:8080. The default port is 8080 and the PORT environment variable overrides it, for example PORT=5000 pnpm start. A sample Alpine app runs in the top half of the screen and the devtools simulator in the bottom half.
Why does the Alpine.js devtools extension need a Chrome file URL permission?
Because it will not work with local files otherwise. You enable it in Chrome settings, on the extensions tab, by choosing Alpine.js devtools, pressing details, and turning on Allow access to file URLs.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/alpine-collective-alpinejs-devtools)Was this useful?