Vue Devtools in the Browser

You open devtools on a Vue site and see Elements, Console, Network — but no Vue tab. The first thing to internalize: Vue Devtools is a browser extension, not a devtools feature of the framework. Install "Vue.js devtools" from the Chrome Web Store or Firefox Add-ons, and it adds two extra panels — Components and Timeline — to the standard inspector on every page.

The extension does not scrape the DOM. It talks to the app through a global hook that the framework broadcasts against. In development builds (process.env.NODE_ENV !== 'production', which is what vite dev sets), the Vue runtime registers itself with window.__VUE_DEVTOOLS_GLOBAL_HOOK__ and announces every application it creates. The extension listens for those announcements and, on the matching page, lights up the Vue panel. That handshake explains the wall you will hit in the field: on a production build the hook is never registered, so devtools sees nothing — not slower, not hidden, absent. A staged deployment that "works but devtools shows nothing" is usually just a production build, and that silence is intentional: shipping the devtools channel would expose component state to any script on the page.

For the rare case where you need inspection in a production-like environment, app.config.devtools = true in main.ts re-enables the hook — do it behind a query parameter or an internal build flag, never in a public bundle, and remember it reveals state (user data in props and stores) to anyone with devtools open.

Practical notes from daily use:

• The panel appears only when it detects a supported app; a plain Vue 3 app under Vite is detected with zero configuration.
• Multiple Vue apps on one page (the micro-frontend case from Application Entry and Mounting) all register, and the panel switches between them via the app selector.
• A @vitejs/plugin-vue-compiled project is detected in dev the moment main.ts runs — no source maps are needed for the tree, only for jumping to source.
• If a component refuses to appear, check that you are on the dev server and not vite preview — preview serves the built bundle, which behaves like production.

A workflow habit before the mechanics: open devtools before reproducing a bug, pin the component you suspect (the pin button freezes the selection so it survives re-renders and route changes), and only then reproduce. Inspecting after the fact often means the state that caused the bug has already been overwritten — and half of debugging reactive UIs is reconstructing what the state was.

Next: what the Components tree actually shows you for a selected component, and how editing what you see teaches you how reactivity updates the DOM.

A related question with a short answer: what about the standalone Vue Devtools app? The Electron-based desktop tool was the primary option for Vue 2 projects and is effectively legacy now — the browser extension covers Vue 3 with better source integration, and nothing in a Vite project needs the desktop variant. If you maintain a Vue 2 app whose workflow centered on the desktop tool, the extension still supports it through the same hook, so the migration is a browser install, not a workflow change. Either way, the skill that transfers between the two is the inspection loop, not the chrome around it.

The Components panel shows the instance tree — every mounted component with its parent-child relationships — which is a different graph from the DOM tree in the Elements panel. Names come from filenames (UserCard.vue → UserCard), so the tree maps directly onto the folder structure you set up in Project Structure and Conventions. A rendered <div> inside a component appears under its owner; a v-for producing six rows shows six DOM children under one component instance, because there is one instance per iteration of the component itself, not per DOM node.

Select an instance and the right-hand pane becomes a live snapshot of that component's world:

The debug loop this enables is mechanical: select the component, watch the sections, click the thing that breaks, and see which value moved. A classic bug — a table showing stale rows — resolves in seconds when the Props pane reveals the parent passed :rows once and the store updated, not the prop. That is the moment people understand props are snapshots of a binding, not a live subscription to the parent's internals: the child re-renders when the parent's value changes, and the pane reflects the current value at all times.

Every value here is editable. Click a prop or a ref's value, type a new one, press Enter, and the running app updates in the same frame — the edit flows through the same reactive channels as user input, re-rendering every dependent component. Two consequences worth burning into memory:

1. Editing is a hypothesis tool. Before writing code to reproduce a wrong state, force the state in devtools: does the UI look correct with status: 'paid'? If not, the bug is in rendering, not in whatever sets status. If yes, the bug is upstream in state management — look at how the value got set.
2. Edits to props are local and transient. Changing a prop on the child patches the child's instance; the parent still holds the original value, so the next parent re-render overwrites your edit. To test a persistent change, edit the source of truth — the parent's ref in its Setup state, or the Pinia store — and watch the value cascade down.

The tree also earns its keep during code archaeology: the selected component shows its file path, so an unrecognizable instance deep in someone else's feature can be traced to its source in one click. Combined with the Elements panel (right-click a DOM node → the inspector highlights the owning component instance), you can move from a visible glitch to the exact component and state slice in under a minute.

Next: the Timeline panel — the tool for bugs that depend on sequence, where inspecting current state is not enough because the damage was done three clicks ago.

Some bugs cannot be answered by looking at state: the UI is wrong now, but the wrongness was caused by an event several steps back — a double-submitted form, a route change mid-fetch, a store write from a component that has since unmounted. Current-state inspection sees only the aftermath. The Timeline panel records the sequence that produced it.

With the Timeline open, Vue logs a stream of events as you use the app: component updates (<TodoItem> updated), emitted events with their payloads (event add with { text: 'buy milk' }), route changes (/cart → /checkout), and store mutations for Pinia/Vuex. Each entry carries a timestamp and a component or route context, and the stream is filterable by component and by event kind — the filter is the difference between a readable timeline and noise on an app that re-renders a hundred nodes per click.

The debugging posture is: open the timeline first, reproduce the bug, then read backwards from the break. Find the last event before the UI went wrong and ask the two questions that usually end the session: what payload did that event carry, and was that event supposed to fire at all. A checkout that silently submits twice shows its story as two identical submit emits 40 ms apart; a blank page after navigation shows a route change racing an in-flight fetch that resolves into state for a component no longer mounted.

Three techniques that extract most of the panel's value:

1. Filter aggressively. Select the suspect component in the Components panel first; the timeline highlights its events, and the rest of the stream can be collapsed. Reproduce in the smallest possible flow — every click you do not need is an entry you must read past.
2. Cross-reference with emits. The Emits section of a component (previous chapter) and the timeline show the same events from two angles: the pane is "everything this one component sent", the timeline is "everything the app did, in order". When they disagree with what you expected, you have found the layer where the bug lives — the child emitted what you see, so the parent's handler is the suspect.
3. Treat the timeline as a recording, not a log to stare at. Entries are inspectable after the fact: click one to see its payload and the component involved. The mental shift is from "watch it happen live" (impossible at 12 events per second) to "reproduce once, then dissect".

What the panel deliberately does not do: it does not time-travel state. Vuex's old devtools offered a limited rewind; Vue's timeline records events, so reverting means handling the event again, not restoring a snapshot. When you need reproducible state replay, that is what a Pinia subscription log or a useLog composable writing to a ring buffer is for — but for the 90% case, an ordered event stream with payloads turns "it just did the wrong thing" into a specific event with a specific payload at a specific moment.

You now have the full early-stage toolkit: scaffolded project, entry file, components, structure, and the two devtools panels. Text Interpolation and Expressions starts rendering data into templates — where most of the bugs you will now catch with devtools actually originate.