Disclosure first, because it changes how you should read the rest: Stele is ours. It is last on this list, its weak spots are written out in the same detail as everyone else’s, and if you finish this and install VisBug instead, that is a fine outcome. What follows is the comparison we wanted when we started building, which did not exist.
The question this is about is narrow. You are on a page, something on it is laid out well, and you want to know how. Not "audit this site", not "debug my own app". Read what is on the screen, understand it, and keep the part you care about.
The five questions
Every tool below gets graded on the same five, because these are what actually separate them once you have used each one for a week.
- Does it show the CSS as somebody wrote it, or as the browser computed it? These are different answers. `padding: 1rem` written in a rule reads back as `16px` computed, and the second one tells you less. A shorthand written once comes back as four longhands. If you are reading a page to learn from it, the written form is the one you want.
- Does it keep conditional rules? A hover rule, a breakpoint, a dark-mode block, and a container query are all things that are not currently applying but are the reason the thing looks the way it does at other sizes. A tool that shows you only the currently-winning declaration hides most of the design.
- Can it measure? Not "what is the padding value", but "what is the actual gap between these two things on screen". Half of what makes a layout feel considered is spacing you cannot read off a single element.
- Does it hold states open? A hover menu closes the instant you move the pointer toward the inspector. This is the single most annoying thing about inspecting other people’s interfaces and most tools do not solve it.
- Does anything survive? You close the tab. Is there a record, or did you just look at something?
There is a sixth question that is not on the list because it is not a feature: what it costs you in permissions. An extension that reads and changes data on all sites can read your session cookies. That is true of every tool here including ours, and it is worth checking what each one asks for and why.
Chrome DevTools
The baseline, free, already installed, and better than most people give it credit for. It is the only tool here reading the browser’s real cascade rather than a reconstruction of it, so layers, container queries and `@scope` resolve correctly, and the Styles pane shows matched rules with their source files and line numbers. Force-state checkboxes hold `:hover` open. The Computed tab tells you exactly what won and why.
Where it falls short is that it is a debugging tool for your own code, and reading somebody else’s page is a different job. The Styles pane is dense by design. The rules arrive in the order the cascade computed them, not in the order that explains anything. There is no measurement between two elements that is not a manual drag. And the moment you close the tab, everything you learned lives in your head or in a screenshot.
If you only ever read one element on one page, this is already the right answer and you should stop here.
CSS Scan
A paid, one-time-purchase extension built around a single motion: hover an element, see its CSS, click to copy. It is genuinely fast, and the speed is the product. There is no panel to arrange and no tree to navigate.
The trade is that speed comes from doing one thing. It is a reader, not a workspace: no measuring between elements, no holding a hover state open while you go look at something, and nothing kept once the tab closes. What it hands you is the block of CSS for the thing under your pointer, which is often exactly what you wanted and occasionally a third of what you needed.
VisBug
Free, open source, and the most fun tool on this list. It gives you design-tool verbs on a live page: pick things, drag them, change type, nudge spacing with arrow keys, drop guides. The best way we know to try a change on a page before deciding it is worth building.
Two things to know. It is a manipulator more than a reader, so the cascade question barely applies to it: you are changing what you see rather than studying how it was specified. And it works by writing attributes onto the page’s own elements, which is fine for a scratch session and means the page’s own scripts can see what you did. Nothing is kept afterwards.
If your instinct when you see a layout is "what if that gap were bigger", install this one.
CSS Peeper
Scoped deliberately at the page rather than the element: the colours in use, the fonts, the images, laid out as something you can look at rather than read. As a first pass on an unfamiliar site it is a faster answer than any of the element-level tools here.
The limit is the same as the strength. It will not tell you how one component is put together, it does not follow the cascade, and conditional rules are outside what it is trying to be. It answers "what is this site made of", not "how does this piece work".
DivMagic
Aimed at turning a piece of a page into code you can paste, Tailwind included, rather than at helping you understand it. If what you want is markup and classes in your editor in two clicks, that is what it does.
It is on this list for completeness more than as a recommendation for this job. As an inspector it is thin: the reading surface is small, conditional rules are not really its concern, and measuring is not part of it. Judge it as a code exporter and it looks a lot better than it does judged as an inspector.
Pluck
A Tailwind-shaped inspector: it reads a page in terms of Tailwind classes and lets you change them live, which on a Tailwind site is a much shorter distance between "I see it" and "I understand it" than raw CSS is.
And that is also the catch. On a site not built with Tailwind, the translation layer is doing a lot of guessing, and a guessed utility class is a worse answer than the declaration it came from. Great in its lane, narrow lane.
Stele
Ours. The part we built for is the first two questions, because that is where we kept getting stuck.
- The CSS as it was written. The panel reads the page’s actual stylesheets rather than the computed style, so a rule reads back the way its author typed it, shorthands intact, custom properties still named rather than already substituted. Cross-origin stylesheets, which a page cannot read for itself, are fetched and parsed so a CDN rule is in the list like any other.
- Conditional rules are kept. Hover, focus and active rules, media conditions, container queries and layers are all shown as their own cards rather than folded away because they are not currently winning.
- Measuring is a first-class verb. Hold Alt over anything to measure from what you pinned, press M to drag a box around any region, G for guides along an element’s edges, R for rulers. Shift-click keeps a measurement on screen while you go find the next one.
- The whole page, not just one element. A second mode answers the page-wide questions in the same panel: every colour it paints ranked by how much of the page it covers, every font family and the type scale, every image with its rendered and natural size, the stylesheet’s own health, the heading and landmark structure, and a set of debug views (outlines, tag labels, an overflow finder, a stacking-context map, the page without CSS, colour-vision filters). Choosing anything in those lists outlines every element behind it.
- Saving is the point of the rest of it. Any element you pin saves into your library with its real DOM and its styles, so the thing you kept is still inspectable months later after the original page has been rebuilt.
- Inspecting, measuring, copying and downloading are free on every plan, with a free account after the first session. Saving uses the library’s ordinary limits.
Now the part that costs you something.
- Chrome only, today. The eyedropper is the only Chrome-specific piece and it is feature-detected, so a Firefox or Safari build is packaging work rather than a rewrite, but it is not done and we are not going to pretend otherwise.
- The panel is our own window over the page rather than a browser side panel, which means it covers part of what you are looking at. It docks to either side, floats, collapses to a pill, and moves out of the way when the thing you pinned ends up underneath it, but it is still a panel on top of a page.
- On a very large page the first pin takes a moment while the rules are indexed. Every pin after that is instant, but the first one is not. The page-wide scan is capped at twenty thousand elements and says when it stopped there, so on a document-sized page those lists are a sample rather than the whole thing.
- While you are inspecting, clicks select instead of activating. That is the correct behaviour and it is still a thing to get used to, so hover deliberately passes straight through and the page’s own hover menus keep working.
How to pick
- You want to understand one element, once. DevTools. It is already there.
- You want the CSS of whatever is under your pointer, fast, and nothing else. CSS Scan.
- You want to change a live page to see whether an idea holds. VisBug.
- You want a site’s colours and fonts at a glance. CSS Peeper.
- You want markup and Tailwind classes pasted into your editor. DivMagic.
- You work in Tailwind and mostly read Tailwind sites. Pluck.
- You want the written CSS with its hover and breakpoint rules, want to measure the gaps, and want the piece to still be there next month. Stele.
The honest summary is that four of these are good at four different jobs and there is no single winner. The one thing we would say is that if your current workflow is "screenshot it and move on", any of them is a large improvement, because a screenshot of a web page throws away every value the browser already computed for you.