One palette, every format: CSS, Tailwind, SCSS, Figma, and AI

Count the places your colors are defined. Go ahead. We'll wait.

There's the globals.css file with custom properties. The tailwind.config with your theme colors. The _variables.scss from when half the project was still on Sass. The Figma library your designer maintains separately. And a README somewhere that lists the hex values, probably outdated.

Five definitions. Five opportunities for drift. And drift always wins.

The drift problem

It starts small. A developer updates the accent color in the CSS file but forgets the Tailwind config. Now var(--color-accent) and bg-accent point to different values. Nobody notices for two weeks because the components that use each approach are on different pages.

Then the designer updates the Figma library. Different shade of accent — slightly warmer. Doesn't tell engineering because it's "just a tweak." Engineering doesn't update their files because they don't know about the change. Now there are three versions of the accent color in production.

The SCSS file hasn't been touched in eight months. Nobody's sure if anything still imports from it. Nobody wants to delete it in case something breaks. So it sits there with the original values, a fossil from a past era of the project.

This isn't a hypothetical. This is every project. The format multiplied. The source of truth didn't.

Why multi-format matters

You can't solve this by picking one format. Teams need multiple formats because they use multiple tools.

CSS custom properties

The foundation. Every modern project uses them. var(--color-bg) works in any CSS context — components, utilities, inline styles, animations. This is the lowest-common-denominator format that everything else builds on.

Tailwind v4 @theme

Tailwind v4 moved theme configuration into CSS with @theme. No more JavaScript config files. Your palette tokens live alongside your custom properties. Classes like bg-accent and text-ink reference the same values as your CSS variables.

SCSS variables

Sass isn't dead. Millions of codebases still use it. If your project compiles SCSS, you need $color-accent: #FC6911; available. Not everyone has migrated to native CSS custom properties, and forcing them to rewrite their build pipeline for a color update is hostile.

Design tokens JSON

The W3C Design Tokens format is the interchange standard. Figma reads it. Style Dictionary transforms it. Token management tools import it. If you need your palette in a tool that speaks design tokens, this is the format.

ASE and GPL

Adobe Swatch Exchange for Photoshop, Illustrator, InDesign. GIMP Palette for GIMP and Inkscape. Print and illustration designers live in these tools. A palette that doesn't export to their format doesn't exist to them.

COLORS.md

The AI format. A markdown file in your project root that AI coding tools read automatically. Roles, hex values, contrast ratios, usage rules. Claude Code, Cursor, and Windsurf pick it up without any configuration. See how it works.

The workflow

Here's how it should work. Here's how it does work with Paletter.

1. Generate

Build your palette. Extract from an image. Generate from color theory. Use a style preset. Start from a hex value and build out. Whatever your starting point, you end up with five colors with assigned roles: Background, Ink, Accent, Support, Neutral.

2. Validate

Check contrast ratios for every text/background pair. Run color blindness simulation. Verify role assignments. Make sure the palette works before you export it anywhere. Catching a problem here takes seconds. Catching it in production takes a sprint.

3. Export all formats

One click per format. CSS custom properties. Tailwind v4 @theme. SCSS variables. Design tokens JSON. ASE. GPL. COLORS.md. Every file contains the exact same hex values because they were generated from the exact same source, at the exact same time.

4. Drop into project

Replace your existing color definition files with the exports. globals.css gets the CSS variables. tailwind.config.css gets the @theme block. The Figma library gets the design tokens import. The project root gets COLORS.md. Done.

5. When colors change

Update the palette in Paletter. Re-export. Replace the files. Every format updates simultaneously because they all come from the same source. The drift is zero because the process makes drift structurally impossible.

What Paletter exports

Every format, from one palette:

• CSS custom properties — semantic variable names with role-based aliases
• Tailwind v4 @theme — native CSS theme tokens, no JavaScript config
• SCSS variables — $color-bg, $color-ink, $color-accent
• Design tokens JSON — W3C Design Tokens Community Group format
• ASE — Adobe Swatch Exchange for Creative Suite
• GPL — GIMP Palette for open-source design tools
• COLORS.md — AI-ready palette with roles, contrast ratios, and usage rules
• COLOUR-SYSTEM.md — full design system documentation with usage guidelines

One palette. Eight exports. Zero drift. See all features.

The math is simple

Maintaining five color definition files manually: guaranteed drift, quarterly "which blue is right" arguments, accessibility regressions when someone changes a value in one place but not the others.

Maintaining one source of truth with automated exports: zero drift, zero arguments, zero regressions. Change the source. Re-export. Ship.

You already know which approach is correct. The only question is when you stop maintaining five files and start maintaining one. See all integrations.