# Export a website design system as a reusable design reference file [Open the live Fudge conversation](https://design.withfudge.com/share/export-a-website-design-system-as-reusable-design-reference-file) Last updated: 2026-08-25 If you want to export a website design system as a reusable design reference file, first capture the page, separate observed details from assumptions, then export the result in the format your project can use. The most useful reference includes typography, color roles, spacing, borders, radii, shadows, gradients, and representative component patterns, not just a list of hex values. ## Use this export method 1. **Choose a representative page.** Use a page that shows the site's main navigation, headline styles, buttons, cards, forms, and content sections. A single landing page may not reveal every state, so note which details are visible and which still need checking. 2. **Capture the page at a useful viewport.** Record the page state, responsive layout, and any visible overlays or interactions. If a design changes between desktop and mobile, treat those as separate references rather than forcing one set of measurements to cover both. 3. **Group details by design role.** Organize findings into type, color, spacing, shape, depth, layout, and components. Roles such as `text`, `muted text`, `surface`, `border`, `accent`, and `danger` are more reusable than unnamed color samples. 4. **Export and review.** Choose Tailwind v4 or CSS for implementation, JSON for tooling, or DESIGN.md for a human-readable handoff. Open the exported file beside the captured page and check that each token has a clear role and a concrete example. Open the example below and compare the captured Linear reference before borrowing its structure. The typography example shows why a useful reference records both the family and where that family appears, rather than saying only that the page uses a sans serif. ## Captured pages [![The system for product development](https://pin.fontofweb.com/6434?format=jpg)](https://design.withfudge.com/share/pin-6434) [The system for product development](https://design.withfudge.com/share/pin-6434) ## Linear typography - **Inter** — weight 400 · Body copy, labels, navigation, and controls. - **Inter** — weight 500 · Headings and emphasized interface text. ## What the reference file should contain A practical file can use this structure: ```text Design reference - Source page and capture date - Viewport and page state - Typography - Family - Weight and size - Line height - Usage: body, heading, label, code - Colors - Role - Value - Contrast or usage note - Layout - Container width - Grid or flex pattern - Spacing scale - Components - Buttons - Cards - Inputs - Navigation - Shape and depth - Border widths - Radii - Shadows - Gradients - Open questions - Details not visible in the capture ``` The `Open questions` section matters. An observed page can show that a button has rounded corners, but it may not prove the exact radius used across every component. A reusable file should preserve that distinction so a developer does not mistake one visible example for an official rule. ## Pick the right output Use **Tailwind v4** when the goal is to start a coded interface with named theme values and utility-friendly tokens. Use **CSS** when the project already relies on custom properties or when designers and developers need a stylesheet they can inspect directly. Use **JSON** when another script, token tool, or design pipeline needs structured values. Use **DESIGN.md** when the main goal is a clear handoff with examples and implementation notes. For a team reference, exporting more than one format can be useful, but keep one source of truth. The readable document should explain the roles, while the machine-readable file should preserve consistent names. Avoid creating names such as `blue-1`, `blue-2`, and `blue-3` when the same values actually serve `accent`, `link`, and `surface-hover` roles. ## Validate before reusing it Run a short review before building from the file: - Can another person identify where each type style appears? - Are font weights and line heights recorded, not only font families? - Are colors named by role and checked against nearby text or controls? - Does the spacing section show repeated patterns rather than one-off gaps? - Are responsive and interactive states marked as unseen when they were not captured? - Does the file say which details were observed and which were inferred? A captured reference is a strong starting point for a new interface, but it is not automatically the original site's internal design system. Treat it as an evidence-based reference, then adapt it to your product's content, accessibility needs, and component states. ## Use this in your AI agent > Inspect the captured website reference and create a reusable design reference for my project. Record typography families, weights, sizes, and line heights; color roles and contrast notes; spacing, borders, radii, shadows, gradients, layout patterns, and visible component styles. Clearly label observed details versus assumptions. Then export the result as Tailwind v4, CSS, JSON, and DESIGN.md, using semantic names and noting any states or responsive details that were not visible. [Install Fudge for your AI agent](/mcp) to run this workflow from your agent. --- Start with what the capture can prove. Include the page URL or reference name, viewport, visible page state, typography families and visible weights, headline and body sizes, line heights, text colors, surface colors, borders, repeated spacing, radii, shadows, gradients, container behavior, and the components shown on the page. For every item, add a usage note. For example, say "muted text in secondary navigation" instead of listing an unnamed gray. Record repeated values as likely patterns, but mark them as observed on this page rather than universal rules. Add an open-questions section for mobile behavior, hover states, form validation, focus styles, and components that do not appear in the capture. A compact file is better than false precision. If you cannot verify whether a value is shared across the site, label it as a page-level observation. You can expand the reference later when more captures become available. --- Begin by mapping the reference's roles to your project's theme names. Create tokens for background, surface, text, muted text, border, accent, and any status colors. Add a type scale with named heading, body, label, and code styles. Then define spacing, radii, and shadows only where the reference shows repeated patterns. Next, build one small test screen with a heading, paragraph, button, card, and form control. Compare it with the reference at the same viewport. Check hierarchy, density, contrast, wrapping, and alignment before expanding the theme. If the result feels too close to one screenshot, revisit the notes and remove values that were only one-off details. Keep the exported file beside the implementation and update both when you learn more. The goal is a clear starting theme that can adapt to your product, not a claim that you own the source site's private design rules. ## Related questions - [Export Website Design Details as Structured JSON](/share/export-a-website-design-system-as-structured-json-design-details) - [Export a Website Design System as JSON Design Tokens](/share/export-a-website-design-system-as-json-design-tokens) - [Export a Website Design System as a Tailwind CSS Theme](/share/export-a-website-design-system-as-tailwind-css-theme) - [Generate color and font tokens from a live website](/share/generate-color-and-font-tokens-from-a-live-website)