uiscanner vs browser devtools: a whole design system, not one element

You already know the move. Right-click, Inspect, click the button you like, read the Styles panel, copy the hex, retype it into your code. Then do it again for the next element. Devtools are the best free reverse-engineering tool ever shipped, and for looking at one node they are unbeatable. The problem is not that devtools are weak. The problem is that a design is not one node, and copying it one node at a time does not scale to the thing you actually want, which is the whole system.

what devtools are genuinely great at

Let's be fair to the tool before contrasting it. When you open the Elements tab and click an element, the DOM tree updates to that node and the Styles tab shows exactly which rules apply, in cascade order, with the winning value at the top. The Computed tab reads every property actually applied, so you never have to guess. You can freeze a :hover or :focus state, edit values live and watch the page respond, and copy an element's styles including any CSS custom properties that were defined. For debugging a specific bug, tracing why one button is the wrong color, or learning how a single clever layout was built, nothing beats it.

That is the shape of devtools: precise, live, and scoped to whatever you clicked. It is a scalpel. The category around it, CSS Peeper, WhatFont, CSS Scan, the various "copy all CSS" tricks, all sharpen the same scalpel. They make inspecting one thing faster. None of them change what you are inspecting: one thing at a time.

where the manual approach falls apart

Reverse-engineering a real design system by hand means inspecting elements one by one, screenshotting color pickers, copying font-family declarations out of computed styles, and building a spreadsheet of spacing values. Guides that teach this workflow, and tools built to replace it, put the honest number on it: roughly 30 to 45 minutes of manual hunting per page, and that is if you are disciplined. Miss a state, miss a breakpoint, miss the one accent color that only appears on the pricing card, and your rebuild looks close but wrong in a way you cannot name.

Three failure modes are baked into the manual approach:

• You see values, not a system. The Styles panel tells you #635bff on this button and 24px on that heading. It does not tell you that #635bff is the primary, that there is a 4-step type scale, or that the spacing follows an 8px rhythm. You have to infer the system yourself from a pile of individual readings, and inference is where mistakes live.
• CSS lists everything, including what never shows. A stylesheet carries colors and sizes that never really render, dead rules, overridden values, a .btn-primary that got restyled three refactors ago. Reading the source, you cannot tell the real primary button from the first one in the CSS. You have to look at the rendered page with human eyes to know which is which.
• There is no structure and no handoff. Devtools never hands you a section-by-section map of how the hero, features, and footer are assembled. And when your AI writes the code, it never saw your panel. You are the courier, retyping values from a browser tab into a prompt, and couriers drop things.

what uiscanner does in one pass

uiscanner is not a faster scalpel. It is a different instrument. You paste a public URL, or scan straight from the address bar like uiscanner.com/https://stripe.com, and one pass gives you the whole teardown: tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure map, and a build prompt tailored to recreate the look. Not a panel to read. A brief to build from.

The part that matters most against devtools is how it reads. uiscanner reads the rendered page with vision, plus the DOM, not just the CSS. So it catches what source-scraping misses: the real primary button rather than the first one declared, whether the hero is centered or split, and which imagery is decorative, with prompts to recreate it as originals rather than copying it. That is the exact judgment call the manual approach forces onto you, made for you, across the whole page at once.

It is transformative by design. It describes and tokenizes a page and never copies or re-hosts the original site's asset bytes. You rebuild in your own stack from the tokens and structure, which is the only fair version of learning from a site you admire. There is a deeper explainer on that in uiscanner vs Snable, which covers the inspector-versus-brief distinction from the extension side.

the loop devtools cannot close

Here is the real gap, and it is not about speed. Devtools end at a panel you look at. uiscanner ends at structured data your agent acts on, because it is also an MCP server and a CLI. One line wires it into Claude Code, Cursor, or Codex:

claude mcp add uiscanner -- npx -y uiscanner-mcp@latest

After that your agent can scan a URL and receive the entire teardown in one call: tokens, structure, brand read, and the build prompt, as data it can build against. There are five tools behind it. ui_probe runs a cheap preflight that spends no scan, ui_teardown does the real scan and returns an id plus a shareable uiscanner.com/t/<id> link, get_teardown re-fetches a finished one, retarget_teardown re-tailors the build prompt to another archetype (landing, dashboard, marketing, ecommerce, portfolio, mobile, general) without re-scanning, and whoami reports your plan. Prefer the CLI? One command:

npx -y uiscanner-mcp@latest scan stripe.com --target landing

That is the loop devtools structurally cannot close. The panel never reaches the model. uiscanner was built so the model gets the design system directly, which is why a Cursor or Claude Code build from a teardown looks like the reference instead of the same generic defaults every agent ships with.

side by side

when devtools are still the right call

This is not a devtools-are-dead pitch. Reach for devtools when the job is a live one: debugging why an element renders wrong, editing values in place to test a fix, freezing a hover state to inspect it, or learning exactly how one specific component was built. For anything scoped to a single node and hands-on, the scalpel wins. uiscanner does not open a live inspector or let you edit the page, and it should not.

Reach for uiscanner when the job is a whole-system one, and especially when an AI is writing the code. You want a page's entire design language, tokens plus structure, captured once and handed to your agent so the rebuild is faithful instead of vibe-coded. Point it at a reference, hand the teardown over, and the agent builds from a real system rather than guessing.

try it

The web app scans a URL from the address bar, or wire the MCP and CLI into your agent with the one-liner above. Setup for every client, plus the Chrome extension, lives at uiscanner.com/mcp, and you can browse example teardowns first, including full breakdowns of the Stripe and Linear design systems. The free plan includes 5 scans per rolling 30 days, and paid plans (Indie at 100, Studio at 400) share one quota across the web app, MCP, and CLI. Keep devtools open for the surgery. Use uiscanner for the system.