Forem: Alexander

Generating fluid CSS clamps from raw Figma typography tokens

Alexander — Wed, 29 Apr 2026 16:30:45 +0000

Your designer hands you a new typography scale. It looks beautiful on their massive studio monitor. You check the mobile designs and the font sizes are completely different. The design file just gives you fixed pixel values for desktop and fixed pixel values for mobile. You now have to write media queries for every single heading level. This is tedious and honestly prone to mistakes.

We can fix this by converting those static pixel values into fluid CSS clamps automatically. You feed in the raw JSON from Figma. You run a script. You get perfect fluid typography that scales smoothly between mobile and desktop viewports.

This means no more media queries for font sizes. Your type just adapts automatically.

Prerequisites

You need Node installed on your machine. You also need a basic project folder with a package.json file. We will use Style Dictionary to process our tokens. It is a fantastic tool for transforming raw data into usable code.

Create a new folder and initialize your project.

npm init -y
npm install style-dictionary

The raw token data

Figma usually exports tokens as JSON. A good typography token structure for fluid type needs a minimum size and a maximum size. Let us look at a simple example for a heading scale.

Create a file called tokens.json in your project root.

{
  "typography": {
    "heading": {
      "large": {
        "min": { "value": "32", "type": "typography" },
        "max": { "value": "64", "type": "typography" }
      },
      "medium": {
        "min": { "value": "24", "type": "typography" },
        "max": { "value": "48", "type": "typography" }
      },
      "small": {
        "min": { "value": "18", "type": "typography" },
        "max": { "value": "32", "type": "typography" }
      }
    }
  }
}

Notice that we store raw numbers here. These represent pixels. We will convert them to rem units in our transformation script to ensure they respect the browser default font size settings.

The fluid typography math

Before we write the script we need to understand how clamp() works. The CSS clamp() function takes three values. It needs a minimum value, a preferred fluid value, and a maximum value.

The preferred value is the tricky part. We calculate it using the viewport width. We want the font size to start scaling up at our minimum viewport width and stop scaling at our maximum viewport width.

Let us assume our mobile viewport starts at 320px. Our desktop viewport stops at 1200px. We convert everything to rem units assuming a base of 16px.

Minimum viewport is 20rem. Maximum viewport is 75rem.

The formula for the preferred value involves finding the slope of the scale. We subtract the minimum font size from the maximum font size. We divide that by the difference between the maximum and minimum viewport widths. We then multiply that slope by the viewport width unit.

It sounds complicated but we can write a JavaScript function to handle the math for us.

Writing the custom transform

We need to tell Style Dictionary how to read our JSON and spit out CSS clamps. We do this by creating a custom build script.

Create a file named build.js in your project folder. We will define a custom transform that looks for our typography tokens and applies the fluid math.

const StyleDictionary = require('style-dictionary')

const minViewport = 20
const maxViewport = 75

function calculateClamp(minPx, maxPx) {
  const minRem = minPx / 16
  const maxRem = maxPx / 16

  const slope = (maxRem - minRem) / (maxViewport - minViewport)
  const intersection = -1 * minViewport * slope + minRem

  const preferredValue = `${intersection.toFixed(3)}rem + ${(slope * 100).toFixed(3)}vw`

  return `clamp(${minRem}rem, ${preferredValue}, ${maxRem}rem)`
}

StyleDictionary.registerTransform({
  name: 'typography/fluid',
  type: 'value',
  matcher: function(token) {
    return token.type === 'typography' && token.path.includes('max') === false
  },
  transformer: function(token, dictionary) {
    const path = token.path.slice(0, -1)
    const tokenGroup = dictionary.tokens[path[0]][path[1]][path[2]]

    const minPx = parseFloat(tokenGroup.min.value)
    const maxPx = parseFloat(tokenGroup.max.value)

    return calculateClamp(minPx, maxPx)
  }
})

This script registers a new transform. The matcher function makes sure we only process the min token. We ignore the max token so we do not generate duplicate CSS variables. The transformer function grabs both the minimum and maximum pixel values from the token group. It then passes them into our math function and returns the final clamp() string.

Configuring the build process

Now we need to configure Style Dictionary to use our new transform. We add this configuration directly to our build.js file.

const config = {
  source: ['tokens.json'],
  platforms: {
    css: {
      transformGroup: 'css',
      transforms: ['attribute/cti', 'name/cti/kebab', 'typography/fluid'],
      buildPath: 'build/css/',
      files: [{
        destination: 'variables.css',
        format: 'css/variables',
        filter: function(token) {
          return token.path.includes('max') === false
        }
      }]
    }
  }
}

const sd = StyleDictionary.extend(config)
sd.buildAllPlatforms()

We tell Style Dictionary to read from tokens.json. We set up a CSS platform. We include our custom typography/fluid transform in the transforms array. We also add a filter to the file output. This filter ensures that the max tokens do not get printed as separate CSS variables. We only want one CSS variable per heading level.

Run your build script from the terminal.

node build.js

The final output

Check your project folder. You will see a new build/css directory containing a variables.css file. Open it up and look at the generated code.

:root {
  --typography-heading-large-min: clamp(2rem, 0.836rem + 5.818vw, 4rem);
  --typography-heading-medium-min: clamp(1.5rem, 0.627rem + 4.364vw, 3rem);
  --typography-heading-small-min: clamp(1.125rem, 0.416rem + 3.545vw, 2rem);
}

You now have perfect fluid typography. The large heading will be exactly 32px on small screens. It will scale up smoothly as the screen gets wider. It will stop scaling when it reaches exactly 64px on large monitors. Everything is converted to rem units so it remains accessible.

You can drop these variables straight into your stylesheets.

h1 {
  font-size: var(--typography-heading-large-min);
}

h2 {
  font-size: var(--typography-heading-medium-min);
}

This approach saves hundreds of lines of CSS. You never have to write another min-width media query just to bump up a font size. Your components become much cleaner and easier to maintain. You also guarantee that the code exactly matches the design intent without manual calculations.

I honestly got so tired of manually copying token values and running these build scripts for every single project. Setting up the pipelines always took away hours of development time. So basically I built a plugin called Design System Sync to handle this automatically. It exports your Figma tokens directly to GitHub or Bitbucket via pull requests. It handles all the W3C formats and even does the CSS variable generation for you. You can check out the Design System Sync website or grab it directly from the Figma Community if you want to skip the manual setup entirely.

Stop exporting SCSS variables from your design system

Alexander — Sat, 25 Apr 2026 07:49:55 +0000

The breaking point

I was reviewing a pull request last Tuesday. A developer on my team was trying to implement a new theme switcher for our dashboard. They had imported a massive JSON file of design tokens from our repository. Then they wrote a giant JavaScript context provider to swap out the values dynamically on the client side.

I left a comment asking why they didn't just use native CSS variables. They replied that our design system pipeline only exported SCSS variables and raw JSON. That moment really cemented a thought I've been having for a long time. If you build products for the web, CSS variables are the only design token format you should care about.

Let's look at how most teams handle design tokens right now. A designer updates a colour in Figma. An automated script pulls that data via an API. The script runs it through a massive transformation pipeline. Then it spits out a dozen different files. You get SCSS variables. You get Less variables. You get a JavaScript object. You get a TypeScript interface. It feels like you are covering all your bases and being incredibly thorough.

But this creates a massive headache for the developers actually building the product. When you give people too many options, they often pick the wrong one for the job.

The problem with compiled tokens

Take SCSS variables as an example. They are entirely static. They compile at build time and then they are gone forever. If you want to support a dark mode using SCSS variables, you have to write twice as much CSS. You end up overriding classes or generating multiple massive stylesheets.

$color-bg-light: #ffffff;
$color-bg-dark: #121212;

.card {
  background-color: $color-bg-light;
}

body.dark-mode .card {
  background-color: $color-bg-dark;
}

This approach is exhausting. It bloats your compiled CSS completely unnecessarily. It makes maintaining UI components a total nightmare. Every single time you add a new element, you have to remember to write the specific dark mode override for it.

Now look at native CSS custom properties. They are incredibly dynamic. They live natively in the browser. They actually understand the cascade. You define your tokens exactly once at the root level. Then you redefine them for your dark theme. Your actual component CSS never has to change at all.

:root {
  --color-bg: #ffffff;
}

[data-theme="dark"] {
  --color-bg: #121212;
}

.card {
  background-color: var(--color-bg);
}

The component just asks for the background colour. The browser figures out which value to use based on the context. This is fundamentally better. It is cleaner. It requires significantly less code.

The debugging nightmare

There is another massive benefit that people completely ignore. I am talking about debugging.

Imagine you are trying to figure out why a button looks wrong on staging. You open Chrome DevTools. If your team uses a JavaScript theme provider or compiled SCSS, inspecting the button just shows a raw hex code. You see #007bff applied to the background. You have absolutely no idea which design token that maps to. You have to go search your codebase for that specific string.

If you use CSS variables, DevTools tells you the exact story. You inspect the button and see var(--button-primary-bg). You know exactly what token is driving the design. You can even click it in DevTools to see where the value is defined and test out changes right there in the browser.

What about utility frameworks?

I hear this specific complaint all the time. People tell me they use Tailwind CSS, so they don't need CSS variables. They just map their JSON tokens straight into their configuration file.

Honestly, that is a missed opportunity. You should absolutely plug your design tokens into your utility framework. But you should configure your Tailwind theme to consume your CSS variables, not raw hex codes. This lets you keep all the benefits of utility classes while letting the browser handle theme switching automatically via the cascade. You don't need to write dark:bg-gray-900 on every single div. You just write bg-surface and let the CSS variable change its own value based on the theme data attribute.

The native app argument

Now I know what some of you are thinking. You are going to say that your company also builds native iOS and Android applications. You need your design tokens in Swift and XML formats.

That is a completely fair point. If you actually deploy native mobile apps, you absolutely need those native formats. But tbh, most teams aren't doing that. Most teams are building web applications. They build dashboards and marketing sites. Yet they still copy the complex architectural patterns used by massive tech giants. You don't need a multi platform token pipeline if you only ship to the web.

Keeping it simple

So what do you actually do about this. You simplify your architecture. You cut out the middleman entirely.

You should export your Figma variables straight to CSS. You skip the massive JSON parsing scripts. You skip the complex build steps. You just get the CSS variables directly into your codebase.

This is exactly why I built the Design System Sync plugin. I wanted a way to skip all that painful boilerplate. The plugin takes your Figma design tokens and exports them directly to GitHub or Bitbucket via automatic pull requests. You can export standard W3C Design Tokens if you need them. But more importantly, you can export perfectly formatted CSS variables right out of the box. It handles multiple modes like light and dark themes automatically.

You can check out the plugin on Figma Community right here: https://www.figma.com/community/plugin/1561389071519901700?utm_source=devto&utm_medium=post&utm_campaign=bot

Or you can read more about how the GitHub integration works on the website: https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot

We really need to stop fighting the browser. Stop writing complicated JavaScript to do a job that CSS handles natively. Stick to custom properties. Your components will be smaller. Your debugging process will be faster. Your developers will be much happier.

Are you still forcing your team to use compiled SCSS variables for design tokens?

Export Figma variables to CSS custom properties using Style Dictionary

Alexander — Wed, 15 Apr 2026 15:00:36 +0000

TL;DR: We are going to take raw JSON from Figma variables and automatically turn it into working CSS custom properties using Style Dictionary.

The problem

Picture this. You are building a new component. You open Figma to check the design. You click on a button and see it uses a specific blue. You copy the hex code. You paste it into your CSS file.

Then the designer decides that blue is actually a bit too dark. They update it in Figma. But your code still has the old hex value. You do not find out until someone complains that the staging environment looks weird.

This happens all the time. Keeping code in sync with design is a massive headache. Tbh it is usually the worst part of building a UI. You just want to write logic and layout. You do not want to be a human copy machine for hex codes.

The good news is we can fix this. Figma lets you use variables for colours and spacing. We can take those variables as JSON and convert them directly into CSS. No more manual copying.

What you need

You only need a few things to follow along. Make sure you have Node.js installed on your machine. We are going to use a tool called Style Dictionary. It is an amazing open source package. It takes raw design data and formats it for any platform. We will focus on CSS today.

Open your terminal and create a new folder for this project.

mkdir figma-to-css
cd figma-to-css
npm init -y
npm install style-dictionary

Step 1: The raw data

First we need some data to work with. When you export variables from Figma they usually come out as a JSON file. The format often follows the W3C Design Tokens draft specification.

Let us create a fake export file to play with. Create a file called tokens.json in your project folder.

{
  "color": {
    "primary": {
      "value": "#0052CC",
      "type": "color"
    },
    "background": {
      "value": "#FFFFFF",
      "type": "color"
    },
    "text": {
      "value": "#172B4D",
      "type": "color"
    }
  },
  "spacing": {
    "small": {
      "value": "8px",
      "type": "dimension"
    },
    "medium": {
      "value": "16px",
      "type": "dimension"
    },
    "large": {
      "value": "24px",
      "type": "dimension"
    }
  }
}

This is a very simple example. Real Figma exports will be much bigger. But the structure is the same. You have categories like colour and spacing. Inside those you have your actual values.

Step 2: Setting up the build script

Now we need to tell Style Dictionary what to do with this JSON file. We need a configuration file. Create a new file called build.js in your folder.

We are going to write a short Node script. This script will read our JSON and output a nice CSS file.

const StyleDictionary = require('style-dictionary');

const config = {
  source: ['tokens.json'],
  platforms: {
    css: {
      transformGroup: 'css',
      buildPath: 'build/css/',
      files: [{
        destination: 'variables.css',
        format: 'css/variables'
      }]
    }
  }
};

const sd = StyleDictionary.extend(config);
sd.buildAllPlatforms();

Let me explain what is happening here. First we import the library. Then we define our configuration object.

The source array tells it where to find our JSON files. You can have multiple files here.

The platforms object is where the magic happens. We defined a CSS platform. The transformGroup tells Style Dictionary to use its built in rules for CSS. This handles things like converting names to kebab case.

The buildPath is where the final file will be saved. Finally the files array tells it exactly what to name the output file and what format to use.

Step 3: Running the build

We just need to run our script now. Go back to your terminal.

node build.js

You should see a message saying the build was successful. Check your project folder. You will see a new build folder. Inside that is a css folder. And inside that is your variables.css file.

The output

Let us look at what Style Dictionary actually generated. Open the variables.css file.

/**
 * Do not edit directly
 * Generated on Fri Oct 20 2023
 */

:root {
  --color-primary: #0052CC;
  --color-background: #FFFFFF;
  --color-text: #172B4D;
  --spacing-small: 8px;
  --spacing-medium: 16px;
  --spacing-large: 24px;
}

Look at that. It took our nested JSON and flattened it out. It added the CSS custom property syntax automatically. It even added a comment warning people not to edit the file directly.

You can now import this CSS file into your main project. When you use --color-primary in your styles it will perfectly match the Figma design.

Handling dark mode

You are probably thinking about dark mode now. Most modern apps need it. Figma handles this using variable modes. You might have a light mode and a dark mode in Figma.

When you export that data you usually get two different JSON files. Or you get one big file with different themes inside. Style Dictionary can handle this perfectly. You just create different source files for each theme. Then you output them to separate CSS files or scope them to specific CSS classes.

Here is a quick example of a dark mode JSON file. Let us call it tokens-dark.json.

{
  "color": {
    "background": {
      "value": "#172B4D",
      "type": "color"
    },
    "text": {
      "value": "#FFFFFF",
      "type": "color"
    }
  }
}

You can update your build script to output a variables-dark.css file too. Then you just load the right CSS based on the user preference. It makes theming incredibly easy to manage.

Automating the whole thing

So basically this script is great. But you still have to get the JSON out of Figma manually. You have to download it and put it in your folder. That still leaves room for human error. I actually got tired of doing this exact workflow. So I built a plugin called Design System Sync to completely automate it. It connects Figma directly to your GitHub or Bitbucket repo. When a designer changes a variable in Figma the plugin automatically generates a pull request with the updated CSS files. You can check it out at ds-sync.netlify.app or find it directly on the Figma Community. It uses the exact W3C formats we just talked about.

Try setting up Style Dictionary in your next project. It honestly changes how you think about CSS architecture.

Building a Figma to GitHub token pipeline that actually works

Alexander — Sat, 11 Apr 2026 18:24:01 +0000

The problem

Picture this. It is a Friday afternoon. Your team is getting ready for a big release. The design team decided earlier that week to tweak the primary brand colour. They changed it from a flat blue to a slightly more vibrant indigo. They updated Figma. They dropped a message in a crowded Slack channel.

And you completely missed it.

The release goes out with the old blue. The designers are frustrated. The developers are annoyed because they were not told properly. Honestly this happens all the time. Hardcoding colours and spacing values into CSS is a recipe for disaster.

We realised we needed a single source of truth. Figma had to be that source. But we also needed developers to review changes before they hit production. We needed a pipeline that turned Figma variables into actual code. And we needed it to happen via standard Pull Requests.

What we tried that didn't work

Our first attempt was pretty basic. We asked the designers to export a JSON file from Figma manually. Then they would zip it and send it to us on Slack. It was a disaster. People forgot to send the file. Versions got mixed up. We had tokens_final_v3_really_final.json floating around.

Next we tried writing a quick local script. A developer would run a command on their machine to fetch the tokens via the Figma REST API. This was slightly better. But it meant developers had to remember to pull the updates. The design team had no control over when their changes went live.

We needed a system where the design team could push changes directly to the codebase. But they had to do it safely. They needed to create a Pull Request automatically.

The architecture

We mapped out a new flow. It had to be simple for both sides.

First the designers update their variables in Figma. When they are happy they run a process to export those variables as standard W3C Design Tokens.

This process talks directly to the GitHub API. It creates a new branch. It commits the JSON file. Then it opens a Pull Request.

Finally a GitHub Action picks up that Pull Request. It runs Style Dictionary to transform the raw JSON into CSS variables. Developers just review the PR and click merge. Everyone stays in their comfort zone.

Implementation walkthrough

Let me show you exactly how we built the core parts of this pipeline.

First you need the tokens in a standard format. The W3C Design Tokens format is the best way to go. It looks something like this.

{
  "colors": {
    "primary": {
      "500": {
        "$value": "#4F46E5",
        "$type": "color"
      }
    },
    "background": {
      "$value": "{colors.primary.500}",
      "$type": "color"
    }
  }
}

The magic happens when you send this to GitHub. You can write a Node script to interact with the GitHub API. You need a personal access token with repo permissions.

Here is a simplified version of the script that creates a new file in a branch.

import { Octokit } from "@octokit/rest";

const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });

async function pushTokensToGitHub(tokensJson: string) {
  const owner = "your-org";
  const repo = "your-repo";
  const branchName = `design-tokens-update-${Date.now()}`;

  // Get the main branch reference
  const { data: refData } = await octokit.git.getRef({
    owner,
    repo,
    ref: "heads/main",
  });

  // Create a new branch
  await octokit.git.createRef({
    owner,
    repo,
    ref: `refs/heads/${branchName}`,
    sha: refData.object.sha,
  });

  // Commit the file
  await octokit.repos.createOrUpdateFileContents({
    owner,
    repo,
    path: "tokens/design-tokens.json",
    message: "Update design tokens from Figma",
    content: Buffer.from(tokensJson).toString("base64"),
    branch: branchName,
  });

  // Open a Pull Request
  await octokit.pulls.create({
    owner,
    repo,
    title: "🎨 Update Design Tokens",
    head: branchName,
    base: "main",
    body: "This PR was automatically generated to sync the latest design tokens.",
  });
}

Once the PR is created you need to turn that JSON into CSS. We use a tool called Style Dictionary for this. You set up a configuration file to tell it how to process the W3C format.

// build.js
const StyleDictionary = require('style-dictionary');

const myStyleDictionary = StyleDictionary.extend({
  source: ['tokens/**/*.json'],
  platforms: {
    css: {
      transformGroup: 'css',
      buildPath: 'build/css/',
      files: [{
        destination: 'variables.css',
        format: 'css/variables'
      }]
    }
  }
});

myStyleDictionary.buildAllPlatforms();

To automate this we added a GitHub Actions workflow. Every time a PR is opened or updated the action runs Style Dictionary and adds the compiled CSS to the PR.

name: Compile Design Tokens

on:
  pull_request:
    paths:
      - 'tokens/**.json'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Setup Node
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Build tokens
        run: node build.js

      - name: Commit compiled CSS
        run: |
          git config --global user.name 'github-actions[bot]'
          git config --global user.email 'github-actions[bot]@users.noreply.github.com'
          git add build/css/variables.css
          git commit -m "chore: compile tokens to CSS" || echo "No changes to commit"
          git push

Edge cases we hit

Building this wasn't totally smooth sailing. We ran into a few annoying edge cases.

The biggest issue was naming conventions. Designers love spaces and capital letters in their Figma variable names. Developers hate that. We had to write a custom transformer in Style Dictionary to clean up the names. It forces everything into kebab case. This prevents CSS errors.

Another tricky part was dealing with light and dark modes. Figma handles modes beautifully now. But exporting them requires you to split the modes into separate JSON files or nest them carefully. We ended up exporting a light.json and a dark.json. Then we configured Style Dictionary to output them into separate CSS files wrapped in media queries.

Math was also a problem. Sometimes designers use calculations for spacing variables. Standard JSON does not understand math formulas. We had to add a parser step to calculate those values before saving the JSON.

Results

Getting this pipeline running changed everything for us.

The friction between design and development dropped to zero. Designers now have total control over the visual foundation. When they want to update a colour they just hit export. A Pull Request pops up. The developers look at the diff to ensure nothing looks wildly broken. Then they merge it.

No more missing Slack messages. No more hunting down random hex codes in the codebase.

I actually spent the last few months turning this exact workflow into a proper Figma plugin. Setting up the GitHub API scripts and token transformers from scratch is a bit tedious. I wanted a tool that just did it out of the box.

I call it Design System Sync. It connects your Figma files directly to GitHub or Bitbucket. It exports your Figma variables into W3C Design Tokens or CSS Variables automatically. It even generates the Pull Requests with visual diffs so developers know exactly what changed.

You can check out the website at https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot. You can also grab it directly from the Figma Community if you want to give it a spin. It has a free tier that covers most small projects perfectly.

Building a solid bridge between design and code takes a bit of effort upfront. But the peace of mind is totally worth it. Let me know if you have tried building something similar for your team.