DESIGN.md Generators

One thing up front, because most "best generator" roundups skip it: we have not yet run our hands-on benchmark of these tools. This page is a category guide based on how each generator type works, with the tools we're aware of named as reported. Our test methodology (same brand into every tool, outputs scored with the official linter) is published below, and results will be added to this page once the benchmark runs. Until then, we won't invent scores.

The five ways to generate a DESIGN.md#

Every generator answers the same question ("what design system is already implied by my existing artifacts?"), but each starts from a different artifact:

If your design system lives in Figma, start there. If it only exists as a shipped product, start from the URL or extension. If it lives in your Tailwind config, extract from code. And if it exists mostly in someone's head, a visual editor, or writing the file by hand, beats all extraction.

What tools exist in each category?#

Below is what each category typically looks like, based on how the extraction method works rather than on specific product claims we haven't verified. Feature details for any individual tool should be confirmed against its own documentation until our benchmark runs.

URL-based generators#

Point one at a domain and it crawls the rendered page (or pages) and emits a DESIGN.md with extracted colors, fonts, and spacing. Several URL-based generators exist; check any specific one's current scope and output format against its own docs before you rely on it.

The category's structural strength and weakness are the same fact: these tools read computed styles. That means the values are real (no hallucinated hex codes), but a marketing homepage often has a different palette and type scale than the logged-in product, and no crawler can extract rules ("tertiary is for one CTA per screen") that were never written down anywhere.

Figma plugins#

If designers maintain named styles or variables in Figma, a plugin can map those to DESIGN.md token groups: the extraction closest to design intent, since names like color/primary carry semantics that rendered CSS has lost. Several plugins exist in this space; we haven't yet verified which ones produce current spec-version output.

The known ceiling: file hygiene. A Figma file full of detached, unnamed fills exports noise, whatever the plugin.

Chrome extensions#

Extensions extract from whatever page you're viewing, including authenticated app screens that URL crawlers can't reach. That makes them the pragmatic choice for capturing your real product UI rather than your landing page. Specific options exist; their names and capabilities are to be confirmed in the benchmark.

Visual token editors#

Visual token editors approach it from the other side: instead of extracting from an artifact, you assemble tokens in a GUI and export a DESIGN.md. This is authoring with training wheels rather than generation, which is exactly right when there's no artifact to extract from, such as a brand that exists only as a logo and a slide deck.

CLI and codebase extraction#

The newest category generates from the repo itself: reading CSS custom properties, Tailwind configs, or existing token files. This space is still emerging; treat any specific product name you come across as unverified until you check its current docs.

You can also do this today with no dedicated tool: point your coding agent at your stylesheets and ask it to draft a DESIGN.md, feeding it the format rules first:

npx @google/design.md spec --rules

That prints the official spec (plus the active lint rules) in a form built for injecting into agent prompts: the agent then drafts against the real schema instead of guessing at it.

How we'll test (and what we'll publish)#

So that "compared" eventually means something, here is the methodology we'll run, published before the results so the scoring can't quietly bend toward a favorite:

1. Same brand for every tool. One brand with a public marketing site, a Figma file, and a Tailwind-based codebase, so every category gets its native input for the same ground truth.
2. Lint pass as the objective baseline. Every output goes through npx @google/design.md lint (v0.3.0, all nine rules) unedited. We'll publish errors and warnings per tool, and the headline number: how many tools produce lint-clean files out of the box.
3. Token accuracy against ground truth. Extracted colors and typography compared with the brand's actual values: exact matches, near misses, fabrications.
4. Rework time. Minutes of manual editing to get each output production-ready: contrast fixes, orphaned-token cleanup, prose that says something.

Until those numbers exist, apply criterion 2 yourself: it's free and takes ten seconds. Run npx @google/design.md lint on any generated file before you commit it. Broken token references show up as errors, contrast failures and orphaned tokens as warnings, all as machine-readable JSON.

Generate, then refine#

Whatever the category, treat generator output as a first draft, not a finished design system. Extraction can recover values; it cannot recover intent, and clearly described intent shapes a generated design more than exact values do.

There's also a sobering baseline from files written by and for real brands: our July 2026 analysis of all 74 files in the awesome-design-md collection found not one file free of lint warnings: 1,341 warnings in total, including 179 WCAG AA contrast violations and 684 orphaned color tokens. If curated files look like that, expect raw generator output to need the same three kinds of cleanup: dedupe and rename tokens semantically, wire every color into a component, and write the usage rules no extractor can know. The refinement workflow, including the three-pass method, is covered in how to write a DESIGN.md, and the spec guide has the full schema when a generated key looks suspicious.

Then look at the result before an agent builds from it: drop the file into the DESIGN.md Viewer and it renders as a navigable brand guideline, entirely client-side. A generated file that "passes lint" but renders as forty near-identical grays is a problem you'll only catch visually.

When should you write by hand instead?#

Generators earn their keep when a design system already exists somewhere: a site, a Figma file, a codebase. Skip them when:

• There's nothing to extract. New brand, no shipped UI: a generator can only echo a template. Start from an annotated DESIGN.md example instead.
• The prose is the point. If your brand's edge is voice and judgment ("never use the accent color twice per screen"), that's authored, not extracted. Generic descriptive words leave room for interpretation; a specific, concrete rule does not, and only you know which specific rules matter enough to write down.
• The file is small anyway. A solid minimal DESIGN.md is about 45 lines. For a side project, writing it takes less time than evaluating five generators.

Next step: generate a draft from whichever artifact you have, lint it, then compare it against the annotated DESIGN.md examples, and preview the result in the DESIGN.md Viewer before your agent builds from it.