Extract a Website's Component Styles
Learn how to inspect a website's buttons, cards, forms, spacing, typography, and surfaces, then turn observed patterns into a usable design reference.
extract a website's component styles
To extract a website's component styles, inspect repeated interface elements across more than one page and record their visible rules: typography, spacing, colors, borders, radii, shadows, states, and layout. The useful result is a component checklist that separates what the site consistently uses from one-off page decoration.
Start with repeated components
Choose a small sample of pages that use the same product or brand system. Look for repeated examples of:
- Buttons, including primary, secondary, ghost, and disabled states
- Navigation links, tabs, breadcrumbs, and pagination
- Cards, panels, tables, and list rows
- Inputs, selects, checkboxes, and validation messages
- Alerts, badges, tooltips, modals, and menus
- Headings, body text, labels, captions, and links
For each component, capture at least one normal state and one changed state. A single screenshot can show appearance, but repeated pages reveal whether a spacing value, border, or color is actually part of the site's shared pattern.
The examples below show two captured Linear pages using the same near-black canvas, muted dividers, compact controls, and a cool accent. Compare the first screen of each before borrowing a pattern. Their shared Inter typography is also a useful reminder to check whether body copy and emphasized text use different weights rather than different families.
Captured pages
Linear typography
- Inter
Weight 400
- Inter
Weight 500
Record styles as a component sheet
Use a table like this while reviewing a site:
| Component | Record | Questions to answer |
|---|---|---|
| Button | size, padding, radius, fill, text weight | What changes on hover, focus, and disabled states? |
| Card | surface, border, radius, shadow, gap | Is the card separated by color, lines, or elevation? |
| Input | height, border, label, placeholder, focus ring | Does focus change color, thickness, or glow? |
| Text | family, size, weight, line height, color | Which styles are reserved for headings or metadata? |
| Layout | max width, columns, gaps, alignment | Does the structure stay stable across viewport sizes? |
Measure relationships before chasing exact pixels. For example, note whether cards share the same radius, whether controls use a common height, and whether section gaps follow a small set of repeated steps. Consistency is usually more valuable than copying every isolated value.
Separate observation from interpretation
Write down what is visible before naming the design intention. "Thin muted divider between rows" is stronger evidence than "minimalist table." "Inter at regular weight for labels and medium weight for headings" is more useful than "modern typography." This keeps the extracted reference easy to check and reduces guesses about what the original team intended.
Also mark uncertainty. If a shadow is hard to distinguish from a border, record both as possibilities until another component confirms the pattern. If a color appears only in one illustration, do not promote it to a design token or component role without seeing it repeated.
Turn the review into a practical system
After collecting observations, group them into reusable roles:
- Typography: families, weights, sizes, line heights, and casing.
- Surfaces: page background, raised panels, controls, overlays, and dividers.
- Controls: shared heights, padding, radii, focus treatment, and states.
- Layout: container width, columns, alignment, and spacing rhythm.
- Feedback: success, warning, error, loading, and selected states.
Use the resulting sheet as a starting point for implementation, not proof of the site's private source code. It describes observed visual behavior. Open the examples below and compare them against your own capture before deciding which patterns belong in your system.
Use this in your AI agent
> Inspect the captured website across its available pages. Identify repeated buttons, cards, forms, navigation elements, tables, alerts, and text styles. For each component, report visible dimensions, spacing, colors, typography, borders, radii, shadows, and state changes. Separate repeated patterns from one-off decoration, mark uncertain observations, and organize the result as a component style sheet that I can use to recreate the interface. Compare at least two pages before calling a pattern shared.
What should I extract first if I only have time to review one page?
Start with the page that contains the most interface variety, usually a product dashboard, settings screen, or page with navigation, forms, cards, and actions. Review the top navigation, main heading, primary action, one content container, one repeated list or table, and any visible feedback message.
Capture these details first:
- Page and panel background colors
- Heading and body font families, sizes, weights, and line heights
- Button height, padding, radius, fill, and text treatment
- Card or panel border, radius, shadow, and internal gap
- Input height, label spacing, border, and focus treatment if visible
- The main container width and horizontal alignment
- Repeated spacing between sections and controls
Do not try to document every icon or image on the first pass. The goal is to find the rules that affect many elements. Then check a second page later to confirm whether those rules repeat. If you only have one page, label conclusions as observations from that page rather than as the site's complete system.
How do I turn extracted component styles into implementation notes?
Organize the notes by shared roles rather than by screenshot location. Start with a short overview of the page background, typography families, spacing rhythm, and surface treatment. Then create one section per component with a base style, variants, states, and open questions.
For example:
- Button: base height, horizontal padding, radius, text weight, primary fill, secondary border, hover change, focus treatment.
- Card: background, border, radius, shadow, header spacing, content padding, footer alignment.
- Input: label style, field height, border color, placeholder color, focus ring, error state.
Use names such as surface-muted, text-secondary, or control-radius only after the visual role is clear. Keep the observed value beside the role so another person can verify it. Add a confidence note when a value appears only once. Finally, compare the notes with another page and mark each rule as shared, page-specific, or still unverified. This produces a practical reconstruction guide without pretending to own the original internal design system.