การเพิ่มสีแบบกำหนดเอง

Every real-world project has a brand identity with specific colors that do not exist in Tailwind's default palette. Adding your brand colors to Tailwind's config unlocks the full utility class API for those colors — you can use them with bg-*, text-*, border-*, ring-*, shadow-*, and every other color utility. Your custom colors also work with opacity modifiers and dark mode variants automatically.

The simplest way to add a custom color is to provide a single hex value with a key name in theme.extend.colors. Tailwind generates a utility class for that exact color. The key becomes part of the class name: a key of brand creates bg-brand, text-brand, border-brand, etc. Single-value colors do not support shade suffixes like brand-500.

For colors that need variation — lighter and darker versions for hover states, backgrounds, and text — define a full shade scale as a nested object. Use the standard Tailwind shade numbers (50, 100, 200, ... 900, 950). This unlocks utilities like bg-brand-100 for subtle backgrounds, bg-brand-500 for the main color, and bg-brand-900 for dark accents.

Manually writing ten hex values for every brand color is tedious. Tools like uicolors.app, palettte.app, or the Tailwind team's online color shades generator take a single base color and produce a full 50-950 scale with perceptually even gradations. Many design tools like Figma also have plugins that export color palettes directly in Tailwind config format.

Inside a color scale object, you can add a DEFAULT key to set the bare utility class (without a shade number) to a specific shade. For example, setting DEFAULT: '#6366f1' means bg-brand renders as the 500 shade. This is useful when your design uses a specific primary shade most often and you want a short class name for it without giving up the full scale.

For colors that change at runtime — like theme colors toggled by user preference — define them as CSS custom properties and reference those variables in your Tailwind config. Use the <alpha-value> placeholder to enable opacity modifier support (bg-brand/50). This pattern is the foundation of multi-theme design systems built on Tailwind.

Sometimes you want to rename or alias existing Tailwind colors — for example, using primary as an alias for indigo so your components stay brand-agnostic. Import Tailwind's color object and use it in your config to reference any built-in color by name. This keeps your palette DRY: change the alias once to update all component classes that use primary.

Instead of naming colors by their hue (indigo, violet), name them by their semantic role in your design (primary, secondary, success, warning, error). Semantic naming makes your components resilient to rebrand: if the brand color changes from indigo to teal, you update one config entry and all components automatically reflect the change.

Custom colors work with dark mode variants the same way as built-in colors. Pair light-shade custom colors for light mode with dark-shade variants for dark mode. If you are using CSS variables for your colors, you can change the variable value in the .dark selector and all utilities that reference the variable update automatically — no extra dark: classes needed.

Custom colors defined as hex values also support Tailwind's opacity modifier syntax (bg-brand-500/75) when Tailwind can convert the hex to an RGB representation. Colors defined as CSS variables with the <alpha-value> placeholder work even better, giving you precise control over opacity at every use site without needing separate utility classes.

After adding custom colors to your config, verify they work by running Tailwind's build and using the classes in your HTML. Check both the generated CSS file (your classes should appear) and the visual output in the browser. Also test dark mode variants, opacity modifiers, and hover states to ensure the full suite of derivative utilities works correctly with your custom colors.

Test your understanding of adding custom colors to Tailwind CSS.

In this lesson you learned: add custom colors in theme.extend.colors as single hex values or full shade scales, use semantic names like primary and error instead of hue names for resilient design, and define colors as CSS variables with <alpha-value> for opacity modifier support. Next up we add custom font families from Google Fonts and local sources.