Design tokens in existing CSS.

The struggle of the second draft

The first pass of a project is always clean. A handful of variables, a clear spacing scale, a focused palette. Then the project grows. A month later you have six slightly different shades of slate gray and four variations of a "base" padding value.

Most teams reach for a manual grep-and-replace approach. You search for #3b82f6, find twelve instances, and replace them with var(--color-primary). Then you realize three of those were supposed to be slightly transparent, or they were hardcoded in a utility class you missed. You spend the afternoon jumping between editor and browser, checking if you broke the UI.

Manual consolidation is high-risk, low-reward. It's the work that gets pushed to the bottom of the backlog because it feels like busywork. But the cost of messy CSS is real. It slows development, makes the design inconsistent, and makes theme updates painful.

The manual limit

Grep is a blunt instrument. It doesn't understand context. It doesn't know the difference between a hex code in a comment and a hex code in a border property. It certainly doesn't help you identify values that are close enough to be merged.

If your CSS looks like this:

.card {
  background-color: #f9fafb;
  padding: 16px;
  border: 1px solid #e5e7eb;
}

.button-secondary {
  background-color: #f3f4f6;
  padding: 15px;
  color: #374151;
}

You have a decision to make. Are #f9fafb and #f3f4f6 two distinct tokens, or did two different people pick "off-white" at different times? Is 15px a deliberate choice or a typo for 16px?

To fix this manually, you have to find every instance, verify it visually in the browser, create a variable in a central file, and then map the original value to that variable. It's a context-switching nightmare.

Consolidating with Kerf

Kerf tokenizes by scanning your actual source files and grouping repeats — including near-duplicates. Because Kerf is a visual editor, you see the impact of each replacement on the live design as it happens.

The Design Token Consolidation tool in Kerf Pro scans your project folder for repeated colors, spacing, and typography. It also surfaces groups of near-duplicate colors and near-duplicate numeric values as merge candidates. You don't write a regex. You select the repeated value, give it a name like --gray-50, and Kerf replaces every instance across your CSS files.

Before and after

Consider a fragmented stylesheet:

/* Before consolidation */
.header {
  color: #111827;
  margin-bottom: 24px;
}

.sidebar-item {
  color: #1f2937;
  padding-left: 23px;
}

.footer-text {
  color: #111827;
}

Kerf flags #111827 and #1f2937 as visually similar grays, and 23px and 24px as near-duplicate spacing values. You confirm the merge; Kerf writes the tokens and rewrites every reference:

/* After Kerf consolidation */
:root {
  --text-main: #111827;
  --spacing-lg: 24px;
}

.header {
  color: var(--text-main);
  margin-bottom: var(--spacing-lg);
}

.sidebar-item {
  color: var(--text-main);
  padding-left: var(--spacing-lg);
}

.footer-text {
  color: var(--text-main);
}

Maintainable, not just tokenized

The goal isn't variables. The goal is a system that matches your design intent. By moving from hardcoded values to tokens inside the editor — where you see the impact immediately — you eliminate the fear of breaking the build.