How to Extract Design Tokens From Visual References Without Guessing
A source-aware method for turning repeated visual decisions into candidate design tokens without pretending screenshots contain exact systems.

Direct answer
Extract token candidates from visual references by measuring repeated roles across several examples, not by sampling isolated pixels. Name each token by purpose, record the source and confidence, test it in your own interface, and validate accessibility. A screenshot can suggest a system; it cannot reveal the original designer’s exact token values or intent.
A visual reference contains outcomes, not source tokens
A screenshot shows rendered pixels after fonts, viewport, browser behavior, assets, and content have interacted. It does not expose the original variables or explain whether two similar values are deliberate. Sampling one color and calling it a brand token confuses an observation with a system decision.
Design tokens are named values intended to carry design decisions across tools and platforms. The Design Tokens Community Group format describes a portable JSON structure for token names, values, types, groups, and references. It is a community-group final report, not proof that any sampled value is correct for your product.[1]
Derive candidates by role and repetition
Choose three to five references that support the same principle. Identify roles before values: canvas, surface, text, muted text, divider, action, focus, danger. Measure representative values, note variation, and choose a candidate that fits your content and rendering environment. Do the same for type scale, spacing rhythm, radii, borders, and motion duration.
Figma’s design-token guidance likewise frames tokens as reusable named values that help maintain consistency across a system. The useful transfer is the relationship—such as action color versus background—not an unexamined hex code.[2]
- Observation: what repeats across the selected evidence.
- Role: the job the value performs in your interface.
- Candidate: the measured or adapted value to test.
- Confidence: high, medium, or low with a short reason.
- Validation: contrast, content stress, viewport, and component checks.
Keep a derivation ledger
For every candidate, record which references supported it, how it was measured, and why it changed during testing. That ledger prevents a future maintainer—or an agent—from presenting an inference as an extracted fact. It also makes later updates cheaper when the evidence set changes.
Test tokens in the hardest real component, not a pristine swatch page. Long headings, small labels, disabled controls, dense cards, and narrow screens expose weak choices quickly. Promote a candidate into the design system only after it works as a relationship across components.
Sesavu’s documentation describes token export as planned direction; the current public prototype does not generate production token files. The method above is deliberately tool-independent.[3]
Questions designers ask
Can AI extract exact design tokens from a screenshot?
It can propose measurements and roles, but it cannot know the source system or intent from pixels alone. Treat results as candidates and keep confidence and provenance.
What should be tokenized first?
Start with the few roles repeated across many components: background, surface, text, muted text, action, focus, border, spacing, and type scale.
Sources checked
- Design Tokens Format Module 2025.10 — Design Tokens Community Group
- Design tokens — Figma
- Sesavu documentation — Sesavu
