Collecting CSS Tokens: From Styling Chaos to a Manageable System

Collecting CSS tokens is not a design-driven whim or aesthetics for aesthetics’ sake. It is an engineering practice aimed at normalizing visual decisions and reducing frontend operational costs.

In this article, we will cover:

• what CSS tokens mean in practical terms;
• how they actually appear in real-world projects;
• which issues token collection exposes;
• and why this process should be automated as part of an audit.

What CSS Tokens Mean in Practice

Stripped of buzzwords, CSS tokens are repeating values that effectively act as constants:

• colors (#0d6efd, rgb(13,110,253))
• font sizes (14px, 1rem)
• line heights
• spacings (8px, 16px, 24px)
• border radii
• shadows, z-index values, and so on

A real e-commerce example:

.button-primary {
    background: #005bff;
    border-radius: 6px;
}
 
.checkout-button {
    background-color: #005bff;
    border-radius: 8px;
}

Formally, these are different values. Conceptually, they represent the same design intent, duplicated without control.

Typical Issues Revealed by Token Collection

1. False Diversity

In one SaaS project, analysis revealed:

• 27 unique shades of blue
• 19 of them differed by 1–3 RGB units

This is a classic symptom of:

• manual copy-paste from Figma;
• the absence of a design contract between teams;
• accumulated technical debt.

2. Spacing Without a System

An admin interface example:

margin-bottom: 12px;
margin-bottom: 14px;
margin-bottom: 16px;
margin-bottom: 18px;

The question is not “which spacing is correct.” The real question is why there are four of them at all.

Token collection allows you to:

• visualize value distribution;
• identify clusters;
• make an informed decision: 8-pt grid, 4-pt grid, or another model.

3. Typographic Drift

In a corporate portal:

• 11 font sizes
• 7 line-height values
• 5 font weights for body text

Once tokens were aggregated, it became obvious that only three typographic roles were actually in use. Everything else was noise.

How CSS Token Collection Works Technically

At a mechanical level, the process is straightforward:

1. Load the page.
2. Collect all CSS (inline and external).
3. Parse declarations.
4. Aggregate values by category:

• colors
• font-size
• spacing
• border-radius

5. Calculate frequency.

Example JSON output:

{
    "colors": {
        "#005bff": 143,
        "#ffffff": 98,
        "#f5f7fa": 34
    },
    "spacing": {
        "8px": 76,
        "16px": 112,
        "24px": 41
    }
}

This is already decision-grade data, not subjective debate material.

Why a Manual Approach Does Not Scale

At an early stage, teams can “agree verbally.” At the point where you have:

• 5+ developers;
• parallel feature branches;
• multiple design sources;

verbal agreements stop working.

Without automated token collection, you:

• lack a reliable snapshot of reality;
• cannot measure the impact of refactoring;
• lose control over regressions.

Real Case: Redesign Without Halting Development

A company with a large marketing site (~120 pages):

Before:

• 4,000+ CSS rules
• 32 colors
• 19 font sizes

Steps taken:

1. Collected tokens across key pages.
2. Sorted them by frequency.
3. Defined a core token set.
4. Migrated incrementally, without a full rewrite.

After:

• 9 base colors
• 6 typographic tokens
• −18% CSS size
• fewer visual regressions during A/B tests

Where Performance Gains Come In

CSS tokens are not just about design:

• fewer unique values → better gzip/brotli compression
• higher CSS coverage
• fewer cascade conflicts
• simpler critical CSS

On large pages, this translates into measurable milliseconds.

Why We Treat This as an Audit Problem

At milten.io, CSS token collection is:

• diagnostics, not a “pretty report” generator;
• a way to expose structure where it appears absent;
• an entry point to standardization, design systems, and scalable frontend architecture.

If tokens cannot be formalized, the system does not exist.

Summary

Reduced to management logic:

• CSS without tokens = an unmanaged asset
• token collection = inventory
• frequency = priorities
• automation = scalability

You can ignore this. But then every redesign will start with: “Let’s just carefully tweak the styles” — and end with another layer of chaos.

If you want to see which CSS tokens actually exist in your project — not which ones “should” — this is exactly the kind of audit that delivers fast and measurable results.