Extract a website border radius scale from a URL

Contents

• [Capture the right page states](#capture-the-right-page-states)
• [Separate observations from proposed tokens](#separate-observations-from-proposed-tokens)
• [Check the details around each corner](#check-the-details-around-each-corner)
• [Turn the findings into implementation rules](#turn-the-findings-into-implementation-rules)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

A useful website border radius extractor turns a captured URL into two separate outputs: the corner values that visibly repeat on the site, and a proposed scale you can use in your own interface. Keep those outputs separate. A website may contain legacy components, decorative artwork, or one-off marketing surfaces that should not become permanent tokens.

Capture the right page states

Start by capturing more than the homepage. Use the website's browser extension or another capture workflow to collect the URL, then review a landing page, a content-heavy page, and at least one interactive state such as a menu, form, dropdown, or dialog. Everyday product screens often reveal the real component rules more clearly than promotional sections.

For each visible corner, record:

• the component type, such as card, button, input, dialog, image, tag, or avatar
• the approximate radius in pixels
• the component height and width
• whether the radius belongs to an outer surface or a nested element
• the page and state where it appeared
• whether the value repeats elsewhere

Do not treat a single screenshot as proof of a complete system. A card may use a larger corner than a compact button, while both still belong to a small and deliberate scale.

Separate observations from proposed tokens

Keep an observation table before creating a token list. A useful format is:

Then group values that have both visual and functional similarities. For example, a site that visibly repeats 6px, 10px, and 16px might support this working scale:

That list is a recommendation, not evidence that the website uses those exact internal names. If the captured pages repeatedly show 7px and 13px, record those values first. Only round them when the difference is not visible or useful in your own implementation.

The captured Linear examples are useful for comparing repeated product surfaces. Both are labeled with Inter, and their notes describe a near-black canvas, muted dividers, compact controls, and one cool accent. Use those details as context when deciding whether a rounded surface belongs to a compact control, a panel, or a larger product section. The supplied evidence does not establish Linear's official radius tokens, so do not claim that it does.

Check the details around each corner

Radius is part of a component's complete shape. Compare it with border thickness, shadow spread, surface color, padding, and component height. Check whether an image follows the outer card radius, whether a nested panel uses a smaller value, and whether focus or hover changes the outline without changing the corner.

A practical review should include at least one button, input, card, dialog, and image container. If every component receives the largest radius, the result will feel soft and inconsistent. If every component receives a unique value, the system will be difficult to maintain.

Turn the findings into implementation rules

Write a short rule beside every proposed token:

• Use radius-sm for compact controls and tags.
• Use radius-md for standard buttons, inputs, and everyday cards.
• Use radius-lg for panels and grouped content.
• Use radius-xl only for large feature surfaces.
• Use the pill value for intentionally capsule-shaped controls, not as a general scale step.

Finish by testing the scale on real components at their actual sizes. A design handoff should include the source page, component, observed value, confidence, proposed token, and any exceptions. This makes the result useful without presenting an inferred scale as the website's official design system.

Use this in your AI agent

> Inspect the captured website references for repeated border radius values across cards, buttons, inputs, menus, dialogs, images, and feature panels. Separate directly observed values from proposed design tokens, compare radius with borders, shadows, padding, and component size, then return a compact radius scale with component examples and implementation rules. Do not present inferred tokens as the website's official internal design system.

Install Fudge for your AI agent to inspect captured page details alongside your other design references.

Keep the source observations and your implementation choices in separate sections. Then map repeated values to semantic roles rather than naming every token after one component. For example:

Use the corresponding values in your Tailwind theme, then test them on a button, input, card, modal, and image container. If one value makes small controls too soft or large panels too sharp, adjust the role boundaries before adding several near-duplicate steps. Keep a note of the original page, component, and observed value so another designer can review the decision.

Capture component dimensions and the details immediately around each corner. Record button and input height, card padding, border thickness, shadow spread, image clipping, and whether nested elements use a smaller radius than their parent. Review focus, hover, selected, and disabled states because a component may keep its shape while changing its outline or surface.

Also compare several page types. Marketing pages can contain decorative exceptions, while settings and product screens show everyday rules. Save each observation with its page and component, then mark which values repeat enough to become tokens. This produces a scale that is easier to defend than a list copied from one screenshot.

Related questions

• Extract a website color system from a URL
• Get the Typography System from a Live Website
• Get the Spacing Scale From a Live Website
• Extract Website Component Styles From a URL