Tailwind vs CSS Variables: Which Should You Use for Color Palettes?

This guide explains when to use each approach, analyzing their impact on performance, scalability, and developer experience—and how to combine them effectively for the best of both worlds.

Approach 1: Tailwind Color Palettes

In a pure Tailwind workflow, colors are defined in your global tailwind.config.js file. This generates utility classes like bg-primary and text-secondary-500 at build time.

// tailwind.config.js
module.exports = {
  theme: {
    colors: {
      primary: "#7c3aed",    // bg-primary
      secondary: "#22c55e",  // text-secondary
      white: "#ffffff",
    }
  }
}

Approach 2: Native CSS Variables

CSS variables (Custom Properties) store values directly in the browser's DOM. They are dynamic, meaning they can be changed instantly at runtime by JavaScript or media queries.

:root {
  --color-primary: #7c3aed;
  --color-secondary: #22c55e;
}

[data-theme="dark"] {
  --color-primary: #a78bfa; /* Lighter purple for dark mode */
}

Comparison: Key Differences

Best Practice: The Hybrid Approach

You don't have to choose. The modern industry standard (used by Next.js, shadcn/ui, and specialized design systems) is to combine both.

1. Define your source of truth in CSS Variables.
2. Reference those variables in your Tailwind Config.

How to implement it:

/* 1. globals.css */
:root {
  --primary: 124 58 237; /* Clean RGB values allows opacity support */
}

// 2. tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        // Tailwind utility uses the CSS variable
        primary: "rgb(var(--primary) / <alpha-value>)", 
      }
    }
  }
}

This gives you the best of both worlds: Tailwind's developer experience (autocomplete, utilities) and CSS Variables' runtime power (theming).

Summary: When to Choose Each