How to Export a Website Color Palette Into CSS, Tailwind, and JSON

Exporting colors sounds simple until you actually try to use the colors in a real project.

A palette on its own is just inspiration.

A copied export is where it starts becoming useful.

That is the reason I cared so much about the export flow in Color Scheme Extractor. I did not want the extension to only say, "here are the colors on this page." I wanted it to help answer the next question:

"How do I move these colors into the thing I am building?"

That is where CSS variables, SCSS, LESS, Tailwind, JSON, and Figma-style tokens come in.

In the extension, the workflow is intentionally direct. You scan a page, open the Tokens area, review Page CSS Variables, look at Generated Tokens, switch between export formats, and copy the output.

The important part is not that there are many export tabs.

The important part is that each format supports a different kind of work.

What the export screen is really for

When Color Scheme Extractor analyzes a page, it can detect the page colors and then organize them into practical outputs.

The export screen has a few pieces that matter:

• Page CSS Variables shows variables already found on the page.
• Generated Tokens turns detected colors into reusable token output.
• Semantic Tokens helps you understand roles like text, info, background, surface, or button colors.
• CSS, SCSS, LESS, Tailwind, JSON, and Figma tabs let you choose the format you need.
• Copy gives you the fastest path from analysis to your project.
• Re-analyze lets you scan the page again after changing pages, themes, or states.

That makes the extension more than a color picker.

It becomes a bridge between a website you are studying and the product you are building.

Start with Page CSS Variables

The first thing I look at is Page CSS Variables.

This section matters because some websites already expose their design system through custom properties. If a page is built with CSS variables, you might see useful values directly from the page itself.

That can include things like:

:root {
  --text: #211922;
  --muted: #000000;
  --info: #2b48d4;
  --background: #ffffff;
  --surface: #e5e5e0;
  --button-primary: #e60023;
}

Those names are valuable because they show intent.

A raw hex value tells you what the color is.

A variable name tells you what the color might be doing.

That difference matters.

If you see --button-primary, you know the color probably controls a primary action. If you see --surface, you know it may be used for cards, panels, or UI backgrounds. If you see --text, you know it carries readable content.

This is the first lesson of exporting well:

Do not only copy colors. Copy the role when the page gives you one.

Then review Generated Tokens

Not every website exposes clean variables.

Some pages use utility classes, inline styles, compiled CSS, design-system abstractions, or colors buried inside components. In those cases, you still need a usable export.

That is where Generated Tokens helps.

Generated tokens take the detected palette and turn it into a more portable structure. Instead of leaving you with scattered swatches, the extension gives you output you can copy into a project.

The idea is simple:

Detected color -> practical token -> export format

A color like #e60023 might become a button or primary token.

A color like #211922 might become a text token.

A color like #ffffff might become a background token.

A color like #e5e5e0 might become a surface token.

This step is not magic. You still need judgment.

But it removes the boring first pass of turning colors into usable code.

Why Semantic Tokens matter

The Semantic Tokens section is one of the most important parts of the workflow because it shifts your thinking from color values to color roles.

A semantic token answers the question:

"What is this color responsible for?"

That question is more useful than "what is the hex code?"

For example:

Text -> #211922
Info -> #2b48d4
Background -> #ffffff
Surface -> #e5e5e0
Button primary -> #e60023

Now you are not just collecting colors.

You are building a system.

This is especially useful when you are studying another website for inspiration. You can avoid copying the brand exactly and instead learn the structure:

• dark readable text
• white background
• soft surface
• strong action color
• blue information color

That structure can become your own palette without becoming a clone of the source website.

Exporting to CSS

CSS is the simplest and most universal export.

If I am building a plain website, a small landing page, or a custom component set, I usually start here.

A clean CSS export might look like this:

:root {
  --text: #211922;
  --background: #ffffff;
  --surface: #e5e5e0;
  --info: #2b48d4;
  --button-primary: #e60023;
}

Then you can use the variables directly:

body {
  background: var(--background);
  color: var(--text);
}
 
.card {
  background: var(--surface);
}
 
.button-primary {
  background: var(--button-primary);
  color: #ffffff;
}

This is the cleanest format when you want browser-native tokens.

CSS variables are also flexible. You can override them for dark mode, themes, sections, or embedded components.

Exporting to SCSS

SCSS is useful when your project still uses Sass variables or a Sass-based design system.

The same palette might become:

$text: #211922;
$background: #ffffff;
$surface: #e5e5e0;
$info: #2b48d4;
$button-primary: #e60023;

Then you can use it in SCSS files:

.page {
  background: $background;
  color: $text;
}
 
.button-primary {
  background: $button-primary;
  color: white;
}

SCSS variables are compile-time values, while CSS variables exist in the browser at runtime.

That is the main difference.

If you need runtime theming, CSS variables are usually better.

If your project already uses Sass and you want the palette inside a build-time style system, SCSS export is convenient.

Exporting to LESS

LESS is not as common in newer projects, but plenty of older dashboards, admin tools, and UI systems still use it.

A LESS export might look like this:

@text: #211922;
@background: #ffffff;
@surface: #e5e5e0;
@info: #2b48d4;
@button-primary: #e60023;

Then:

.panel {
  background: @surface;
  color: @text;
}

The reason Color Scheme Extractor includes formats like LESS is simple: export should meet the project where it is.

Not every useful project is using the newest stack.

Sometimes the best export is the one that fits the codebase in front of you.

Exporting to Tailwind

Tailwind export is the one I use most often for modern landing pages and small product UIs.

If you are using Tailwind v4-style theme variables, the palette can become:

@theme {
  --color-text: #211922;
  --color-background: #ffffff;
  --color-surface: #e5e5e0;
  --color-info: #2b48d4;
  --color-button-primary: #e60023;
}

Then the colors can appear as utilities:

<section class="bg-background text-text">
  <div class="bg-surface">
    <p class="text-info">Palette exported into Tailwind.</p>
    <button class="bg-button-primary text-white">Export</button>
  </div>
</section>

For older Tailwind projects, you may still map colors in tailwind.config.js:

module.exports = {
  theme: {
    extend: {
      colors: {
        text: '#211922',
        background: '#ffffff',
        surface: '#e5e5e0',
        info: '#2b48d4',
        'button-primary': '#e60023',
      },
    },
  },
}

Tailwind export is useful because it turns extracted colors into a vocabulary you can use while building UI.

Instead of thinking in hex codes, you write classes around roles.

Exporting to JSON

JSON is best when the palette needs to travel.

Use JSON when you want to store, transform, compare, or pass tokens between tools.

A JSON export might look like this:

{
  "text": "#211922",
  "background": "#ffffff",
  "surface": "#e5e5e0",
  "info": "#2b48d4",
  "buttonPrimary": "#e60023"
}

That is useful for scripts, design token pipelines, internal tools, or database storage.

You can also generate other formats from JSON:

const palette = {
  text: '#211922',
  background: '#ffffff',
  surface: '#e5e5e0',
  info: '#2b48d4',
  buttonPrimary: '#e60023',
}
 
const css = Object.entries(palette)
  .map(([name, value]) => `  --${name}: ${value};`)
  .join('\n')
 
console.log(`:root {\n${css}\n}`)

This is why JSON is a strong source-of-truth format.

It does not style the page directly, but it can feed the systems that do.

Exporting for Figma

The Figma tab exists because design work does not always start or end in code.

Sometimes you want the extracted palette to become a design reference. Sometimes you want to document a palette for a client, prototype, or design system. Sometimes you want the same semantic names in design and development.

A Figma-friendly token export is useful when you want names like:

Text
Background
Surface
Info
Button Primary

Those names are easier to reason about than anonymous swatches.

Again, the value is not only the color.

It is the label.

When to use each export format

Here is the simple version.

Use CSS when you want browser-native variables and flexible theming.

Use SCSS when your project already uses Sass and build-time variables.

Use LESS when you are working in a legacy or LESS-based styling system.

Use Tailwind when your UI is built with utility classes and theme tokens.

Use JSON when the palette needs to be stored, transformed, generated, or shared between tools.

Use Figma when the palette needs to move into design documentation or visual systems.

The best export is not the most impressive format.

The best export is the one that fits your next step.

My personal export workflow

When I use Color Scheme Extractor, I usually follow this flow:

1. Scan the website.
2. Open the Tokens tab.
3. Check Page CSS Variables first.
4. Review Generated Tokens.
5. Use Semantic Tokens to understand color roles.
6. Switch to the export format I need.
7. Click Copy.
8. Paste into the project.
9. Rename or trim tokens if needed.
10. Re-analyze if the page state or theme changes.

The Re-analyze step is useful because websites are not static. A page might have a dark mode, logged-in state, modal, pricing section, or different route with different colors.

If the visible page changes, the palette can change too.

That is why export should be tied to what you are actually looking at.

The mistake to avoid

The mistake is exporting everything.

Just because a color appears on a page does not mean it deserves to be in your design system.

Some colors are noise.

Some are one-off decorations.

Some come from embedded assets.

Some are too low contrast for the role you want.

Before exporting, ask:

Would I intentionally use this color in my project?

If the answer is no, leave it out.

A smaller clean export is better than a giant messy one.

The final lesson

Exporting a palette is not just a technical step.

It is the moment where color inspiration becomes working UI infrastructure.

CSS makes the palette usable in the browser.

SCSS and LESS make it fit older style systems.

Tailwind turns it into utility classes.

JSON makes it portable.

Figma makes it easier to document and share visually.

But the real skill is not clicking the export tab.

The real skill is knowing what each color is for.

Once you know that, exporting becomes easy.

And building with the palette becomes much faster.