# Inspect any site with Lit Inspector

> Install the Lit Inspector extension for Chrome or Firefox and inspect the Lit components on any page, production builds included.

Inspect the Lit components on any page, including production builds and sites you don’t serve, from a **Lit** tab in your browser’s DevTools. Skip this page if you only debug your own Vite app: the panel in Vite DevTools does more there.

[![](/_astro/chrome.CRByiUFQ.svg)Get it on theChrome Web Store](https://chromewebstore.google.com/detail/lit-inspector/faojnglflincboehhgkjgehnapjgiieh?utm_source=docs\&utm_medium=store-button\&utm_campaign=guides-devtools-browser-extension)[![](/_astro/firefox.1bWoP6pv.svg)Get it on theFirefox Add-ons](https://addons.mozilla.org/firefox/addon/lit-inspector/?utm_source=docs\&utm_medium=store-button\&utm_campaign=guides-devtools-browser-extension)

![The Lit tab in Chrome DevTools, listing a page's Lit components in a tree with the selected element's properties beside it.](/_astro/screenshot-1-components.Cqhps63o_28xoLQ.webp)

Lit Inspector is the same panel the Vite plugin serves, running inside a browser extension with no server behind it. The browser injects the runtime itself, so a page’s Content Security Policy can’t block it.

## Install

### Chrome

Install Lit Inspector from the [Chrome Web Store](https://chromewebstore.google.com/detail/lit-inspector/faojnglflincboehhgkjgehnapjgiieh?utm_source=docs\&utm_medium=install-section\&utm_campaign=guides-devtools-browser-extension) with **Add to Chrome**. Chrome keeps it up to date.

To run a build that isn’t in the store yet, every [GitHub release](https://github.com/oddcelot/vite-plugin-lit/releases) also carries `lit-inspector-<version>.zip`, which you load by hand:

1. Unzip it into a folder you keep. Chrome loads the extension from that folder every time it starts.

2. Open `chrome://extensions` and turn on **Developer mode**, top right.

3. Click **Load unpacked** and pick the folder with `manifest.json` in it.

An unpacked extension doesn’t update itself, and it sits next to the store version as a second **Lit Inspector**; turn one of them off.

### Firefox

Install Lit Inspector from [Firefox Add-ons](https://addons.mozilla.org/firefox/addon/lit-inspector/?utm_source=docs\&utm_medium=install-section\&utm_campaign=guides-devtools-browser-extension) with **Add to Firefox**. You need Firefox 140 or later. Firefox keeps it up to date.

To run a build that isn’t on Firefox Add-ons yet, load the zip from a [GitHub release](https://github.com/oddcelot/vite-plugin-lit/releases) by hand:

1. Download `lit-inspector-<version>-firefox.zip`.

2. Open `about:debugging#/runtime/this-firefox`.

3. Click **Load Temporary Add-on** and pick the zip. **Lit Inspector** appears under Temporary Extensions.

Note

A temporary add-on is gone when Firefox closes; load it again after a restart.

## Enable it on a site

The extension asks for no site access at install and does nothing until you turn it on for a site.

1. Open DevTools on the page and go to the **Lit** tab.

2. In Chrome, click **Enable on this site** and allow access when Chrome asks. In Firefox, open the extension’s toolbar button (in the Extensions menu until you pin it) and click **Enable on this site**.

3. The page reloads. The **Lit** tab lists the page’s components.

Firefox enables a whole host on every port, so `http://localhost:5173` turns on `http://localhost`. To turn a site off, click **Disable on this site** at the bottom right of the **Lit** tab.

## Where a component is defined

Without the Vite plugin, no build step tells the extension where a component lives. If the page ships sourcemaps, the extension works it out from them. The original file and line show in the details pane’s **defined** row, in the **Updates** view’s header for a component, and in the **Timeline**’s span details. A click opens it in your editor on a Vite dev server, and in Chrome’s **Sources** panel elsewhere; see [Open a component in your editor](#open-a-component-in-your-editor).

The extension fetches the page’s scripts and their sourcemaps from the site to do this, so the maps must be reachable from the page. It only sees components defined after it injects, which on an enabled site is before the page’s first script runs.

The details pane’s **rendered** row, which names the template tag that created an element, comes from the template’s own text: the extension records each Lit template as it is made, then looks for that template literal in the sources the sourcemaps carry, or in the script itself when there are none. It finds templates whose text the build left as written, so a build that minifies template HTML, or two templates with the same text, can leave the row out or name the first of them. Elements created any other way, such as with `document.createElement`, have no **rendered** row.

## Read component documentation

The details pane shows what a [Custom Elements Manifest](https://github.com/webcomponents/custom-elements-manifest) says about the selected component: its description, events, CSS custom properties, and descriptions on the property, attribute, slot and part rows. See [Read a component’s documentation](/guides/devtools/components/#read-a-components-documentation).

The **Component docs** section of the **Settings** tab lists the manifests the extension reads for the site, in order. A component’s docs come from the first switched-on manifest that describes it, so when two describe the same tag, the higher one wins. Each entry has a switch, to skip it without losing it, and arrows to move it.

* **Linked by the page.** Manifests the page names with `<link rel="custom-elements-manifest" href="…">` are listed first and marked **linked by page**. They can be switched off and moved, but not removed, as the page would bring them back.
* **Added by you.** Enter a path such as `/dist/custom-elements.json` or a full URL on the same site and click **Add**. An added entry has **Remove**.
* **Found.** Some sites host a manifest without linking it; Web Awesome’s docs, for one, serve theirs at `/dist/custom-elements.json`. The extension looks for a `custom-elements.json` beside the page’s scripts and in the folders above them, a few requests to the site itself, and offers each it finds below the list with **Use it**, which adds it, and **Always ignore**. An ignored one stays there with **Use it** and **Reset**. While one is on offer, the bottom of the **Lit** tab says so: **Review in Settings** opens the section, **Not now** hides the note until the panel opens again.

The list, its order and its switches are remembered per site.

* **On another site.** A manifest on a CDN or any other site, such as Web Awesome’s at `https://cdn.jsdelivr.net/npm/@awesome.me/webawesome@3/dist/custom-elements.json`, can be added by its full URL. In Chrome, **Add** asks for access to that site first; if you decline, it isn’t added. A page that links a manifest on another site gets an entry with **Allow access to …**, and it isn’t read until you do. Only the manifest is fetched there; the extension registers no scripts on that site, and removing the last entry for it gives the access back. Firefox can’t ask for access from DevTools, so there such an entry says it isn’t read.

## Open a component in your editor

On a page your Vite dev server serves, the **defined** and **rendered** links open the file in your editor, with or without the Vite plugin. The extension asks the dev server to open it, so the editor is the one that server launches. Set `LAUNCH_EDITOR` in the server’s environment to choose it. Hovering a link says where it opens: **Open in your editor** or **Open in Sources**.

The extension uses the plugin’s endpoint when the plugin serves it, which it does with `sourceOverlay` on. Otherwise it uses Vite’s own `/__open-in-editor`, under the page’s `base` when it has one. Vite opens a path relative to the folder it was started in, so the extension sends an absolute path once it knows the project folder. It finds the folder from any absolute path the page names, such as Astro’s for an element in `.astro` markup.

When it can’t find the folder, the bottom of the **Lit** tab says files open only if Vite runs in the project folder. That is how `vite` usually starts, so links work. If you started the server elsewhere, click **Set project folder…** and enter the folder. The extension checks it against a module the page loaded before keeping it for the site. **Don’t show again** hides the note for that site.

Without a dev server, the links open in the **Sources** panel instead.

## Open in the browser’s own panels

The Lit panel and DevTools’ own panels hand off to each other:

* The details pane’s **Reveal in Elements** button, beside the scroll-into-view button, selects the element in the **Elements** panel. It works in Chrome and in Firefox, wherever DevTools offers `inspect()`.
* The other way round, selecting a node in the **Elements** panel selects its row in the Lit panel’s **Components** tab: the node itself if the tree lists it (a Lit element, an undefined tag or a non-Lit custom element), else the nearest one around it, through shadow roots.
* The **Elements** panel’s sidebar gets a **Lit** tab beside Styles and Computed. It shows the Lit details for the selected node, or the nearest Lit element around it: properties you can edit, state, attributes, slots and parts, and the **defined** and **rendered** links. It follows the Elements selection, so you can stay in Elements and read a component’s state there.
* In the **Console**, `$lit` is the element selected in the Lit panel, next to `$0` for the Elements panel’s.
* Where no dev server can open them in your editor, the **defined** link and, on a page built with the Vite plugin, the **rendered** link open in the **Sources** panel at that line. A source the plugin stamped is a file path, so the extension looks up the URL the page loaded for that file and opens it. If the page didn’t load the file, nothing opens. If you’ve connected a Chrome DevTools workspace to the project folder, Chrome maps the file to your disk and you can edit it there.

Opening in **Sources** needs Chrome: Firefox has no way for an extension to open it. In Firefox the links open in your editor on a Vite dev server, and stay plain text elsewhere, with a note at the bottom of the **Lit** tab saying why.

## Pause on an update or a change

Because the Lit panel runs inside DevTools, it can stop the page in the debugger. The details pane has a **break on** line with **update** and **render** toggles: arm one and the page pauses the next time the selected element enters `update()` or `render()`. Hovering a row under **Properties** or **State** shows a pause toggle for that property; armed, the page pauses when the property changes. A write of the same value, or one its `hasChanged` rejects, does not pause.

The pause stops in a small wrapper of the extension’s. Its `litBreakpoint` variable in the **Scope** pane names the element and, for a property, the old and new value. Step into the call to reach the element’s own `update()` or `render()`, or step out to find the code that set the property. Breakpoints cover only the selected instance, never other elements of the same class, and they are all removed when you select another element or the page reloads.

## What the extension can’t do

The extension has no dev server of its own. Hot patching, snapshot export and the MCP tools need the Vite plugin, and so do **Rendered at** links in the Updates view and the Timeline. Opening in your editor needs a Vite dev server behind the page. Render events on the timeline need Lit’s development build. It sees the top frame of `http:` and `https:` pages only.

Enabled on a Vite dev server that runs the plugin, the extension and the plugin share one runtime: the extension’s loads first and serves the page, and the plugin’s panel in Vite DevTools sees the same tree. The Components tab says so in a line above the tree.

The extension collects no data. Its network requests go to the enabled site itself. It fetches the site’s scripts, sourcemaps and Custom Elements Manifests, to find where components are defined and what their documentation says. On a Vite dev server it also asks which editor endpoints the server has, checks which files it serves to find the project folder, and asks it to open files you click. It stores the sites you enabled and your panel settings in your browser.

## Related

[DevTools features by host](/reference/devtools-hosts/)Every panel feature, compared across the Vite plugin and both extensions.

[Lit Inspector privacy policy](/reference/extension-privacy/)What the extension stores, the permissions it asks for, and how to remove its data.