Tailwind CSS Colors: A Complete Guide to Colours, Shades and Custom Palettes

Tailwind CSS Colors are built around a simple idea: instead of managing individual colour values throughout a project, you work with an organised system of colour names and shades. That system makes it easier to keep buttons, text, backgrounds, borders, forms, and other interface elements visually consistent.

If you are starting with a brand colour and want to turn it into a Tailwind-ready shade scale, the Tailwind Color Generator can help you create a 50 to 950 colour range and explore how the shades work together.

The colour system becomes especially useful when a project grows beyond a few pages. A developer might need one shade for a background, another for a border, a darker shade for text, and a stronger version for a hover state. Tailwind's numbered colour system provides a predictable way to organise those decisions.

For designers and developers who work with different colour formats and palettes, Free Color Tool provides a collection of tools for exploring colours and creating colour combinations. Understanding the Tailwind system first, however, makes it much easier to decide which colours actually belong in a project.

The current Tailwind palette follows an 11-step scale from 50 through 950, and Tailwind's newer versions also use OKLCH values in the default palette. This gives modern projects a structured starting point while still allowing developers to customise the system when a brand or design system needs something different.

What Are Tailwind CSS Colors?

Tailwind CSS colours are values that can be applied through utility classes.

For example:

<button class="bg-blue-600 text-white">
  Get Started
</button>

In bg-blue-600:

• bg identifies the background colour utility.
• blue identifies the colour family.
• 600 identifies the shade.

The same colour system can be used for other properties:

<p class="text-blue-600">
  Learn more
</p>

<div class="border border-blue-200">
  Content
</div>

Tailwind also supports colour utilities with variants. For example, hover:text-blue-600 applies a colour when an element is hovered, while responsive variants can apply different colour utilities at different breakpoints.

This is one reason the Tailwind colour system is useful for component-based development. Colour choices can remain close to the component that uses them rather than being scattered across separate CSS rules.

How the Tailwind Colour Scale Works

The current default Tailwind colour system uses these shade numbers:

Shade	Position in the scale
50	Lightest
100	Very light
200	Light
300	Light-medium
400	Medium-light
500	Middle range
600	Medium-dark
700	Dark
800	Very dark
900	Deep
950	Darkest

Tailwind's official documentation describes every default colour as having 11 steps, with 50 being the lightest and 950 the darkest.

For example, the blue scale contains:

blue-50
blue-100
blue-200
blue-300
blue-400
blue-500
blue-600
blue-700
blue-800
blue-900
blue-950

The numbers should not be treated as fixed design instructions. Tailwind does not say that every button must use 500 or every hover state must use 700.

The number simply tells you where the shade sits within that colour family.

What Does 500 Mean in Tailwind CSS?

The 500 value is one of the positions in Tailwind's colour scale.

You will often see classes such as:

bg-blue-500
text-green-500
border-purple-500

because the middle of a scale can be useful for accents and primary interface elements.

However, there is no requirement to use 500 as your main brand colour.

For example, a design might work better with:

<button class="bg-blue-600">
  Continue
</button>

while another project may use blue-500.

The choice should come from the visual design, contrast requirements, component state, and surrounding colours rather than the number alone.

Tailwind CSS Default Colour Palette

Tailwind provides a large default palette covering colourful hues as well as neutral options.

The current documentation includes families such as:

• Red
• Orange
• Amber
• Yellow
• Lime
• Green
• Emerald
• Teal
• Cyan
• Sky
• Blue
• Indigo
• Violet
• Purple
• Fuchsia
• Pink
• Rose
• Slate
• Gray
• Zinc
• Neutral
• Stone
• Taupe
• Mauve
• Mist
• Olive

Each default colour family has the same 50 to 950 structure.

This means a developer can move between colour families without having to learn a completely different naming system.

For example:

blue-100
green-100
purple-100
red-100

all follow the same basic pattern.

The newer mauve, olive, mist, and taupe palettes were added to provide additional neutral-adjacent options with different visual characteristics.

Tailwind Neutral Colours

Neutral colours deserve particular attention because they are used extensively for text, backgrounds, borders, cards, navigation, and application surfaces.

Tailwind includes several neutral families, including:

• Slate
• Gray
• Zinc
• Neutral
• Stone

They are not simply interchangeable greys. Each family has its own visual character.

For example, a cool-toned interface may use slate for text and surfaces, while a warmer design may work better with stone or another warm neutral.

A simple interface might use:

<div class="bg-slate-50 border border-slate-200">
  <h2 class="text-slate-900">
    Account settings
  </h2>

  <p class="text-slate-600">
    Update your preferences below.
  </p>
</div>

Using several shades from the same family helps create hierarchy without introducing unnecessary colours.

How to Use Tailwind CSS Colors

Tailwind colour utilities can be applied to many different parts of an interface.

Background colours

<div class="bg-indigo-600">
  Dashboard
</div>

Text colours

<p class="text-slate-700">
  Additional information
</p>

Border colours

<div class="border border-slate-300">
  Card
</div>

Hover colours

<button class="bg-blue-600 hover:bg-blue-700">
  Save changes
</button>

Focus colours

<input class="border-slate-300 focus:border-blue-600" />

Responsive colour changes

Tailwind allows responsive variants to be combined with colour utilities:

<div class="text-blue-600 md:text-green-600">
  Responsive colour
</div>

This is useful when a design intentionally changes between layouts or screen sizes.

Choosing Shades for Different UI Elements

A colour scale becomes more useful when its shades have different jobs.

For example, an information panel might use:

<div class="bg-blue-50 border border-blue-200">
  <h3 class="text-blue-900">
    Information
  </h3>

  <p class="text-blue-700">
    Your settings have been updated.
  </p>
</div>

Here:

• blue-50 creates a subtle background.
• blue-200 separates the panel from surrounding content.
• blue-900 provides strong heading contrast.
• blue-700 creates a less intense supporting text colour.

This is more flexible than using the same shade for every element.

A useful starting convention is:

Tailwind shades	Potential role
50 to 100	Tinted backgrounds
200 to 300	Borders and subtle accents
400 to 500	Accents and prominent elements
600 to 700	Buttons, links and active states
800 to 900	Strong text and dark elements
950	Very dark surfaces

These are conventions, not Tailwind rules. Always test the actual colour combination.

Tailwind Colour Palette vs Colour Scale

A colour scale contains different shades of one colour.

For example:

blue-50
blue-100
blue-200
blue-300
...
blue-950

A colour palette is the larger collection of colour families used by a project.

For example:

Blue
Green
Purple
Red
Amber
Slate

A design system can therefore contain several colour scales that together form one palette.

This distinction matters when designing a website because you may not need every colour family. A project could use one primary scale, a neutral scale, and a few semantic colours for status messages.

Building a Tailwind Colour Palette

A useful colour palette starts with the purpose of the website rather than the framework itself.

A typical interface may need:

Primary
Secondary
Neutral
Success
Warning
Error
Information

Each role can then be assigned one or more shades.

For example:

Primary: blue
Success: green
Warning: amber
Error: red
Neutral: slate

You can then select the appropriate shades from each scale.

The important part is consistency. If primary-600 is used for primary buttons, randomly replacing it with another shade throughout the website makes the system harder to understand.

For projects that need several colours working together rather than one single shade scale, the Color Palette Generator can be useful for exploring broader colour combinations.

Creating Custom Tailwind Colors

Tailwind's default palette is designed to cover many common use cases, but a brand may require colours that are not included.

For example, a company may have a specific purple that needs to appear consistently across:

• Buttons
• Links
• Navigation
• Illustrations
• Marketing sections
• Product screens

Instead of repeatedly writing a HEX value, the colour can become part of the Tailwind theme.

This gives the project a reusable name such as:

brand-500

or:

primary-600

The exact naming convention is up to the project.

Custom Colours in Tailwind CSS v4

Tailwind CSS v4 introduced a CSS-first approach to customisation.

Instead of relying on the older configuration-heavy workflow, current Tailwind documentation uses the @theme directive to define theme variables. Colour variables use the --color-* namespace.

For example:

@import "tailwindcss";

@theme {
  --color-brand-500: #7c3aed;
}

Once the colour is defined, Tailwind can generate utilities such as:

<button class="bg-brand-500 text-white">
  Start now
</button>

The same theme colour can be used with other utilities:

<p class="text-brand-500">
  Learn more
</p>

<div class="border-brand-500">
  Content
</div>

The @theme approach makes the colour part of the project's design-token system rather than treating it as an isolated CSS value.

Creating a Custom 50 to 950 Scale

If one custom colour is not enough, you can define a complete scale.

For example:

@import "tailwindcss";

@theme {
  --color-brand-50: #f5f3ff;
  --color-brand-100: #ede9fe;
  --color-brand-200: #ddd6fe;
  --color-brand-300: #c4b5fd;
  --color-brand-400: #a78bfa;
  --color-brand-500: #8b5cf6;
  --color-brand-600: #7c3aed;
  --color-brand-700: #6d28d9;
  --color-brand-800: #5b21b6;
  --color-brand-900: #4c1d95;
  --color-brand-950: #2e1065;
}

This creates a familiar Tailwind-style structure for the custom colour.

You can then use different shades for different component states:

<button class="bg-brand-600 hover:bg-brand-700 text-white">
  Get started
</button>

The actual values should be selected and tested for the project rather than copied simply because they form a visually pleasing gradient.

Overriding Tailwind's Default Colours

Tailwind also allows existing default colours to be overridden.

For example, if a project needs its own version of the gray scale, the corresponding --color-gray-* variables can be redefined in the theme.

This can be useful when a design system already has established neutral colours but the team wants to keep familiar utility names.

Instead of changing every component from:

text-gray-700

the project's theme can define what gray-700 means.

That keeps the markup familiar while allowing the visual system to be customised.

Creating a Completely Custom Palette

Some projects may not need Tailwind's default colour families at all.

The current documentation allows the default colour namespace to be disabled and replaced with a custom palette using:

@theme {
  --color-*: initial;

  --color-brand: #3f3cbb;
  --color-midnight: #121063;
  --color-surface: #f8fafc;
}

This approach can be useful for highly controlled design systems where every available colour needs to be intentional.

For smaller projects, however, keeping the default palette and adding a few custom colours may be easier to maintain.

Tailwind CSS v3 and v4 Colour Configuration

If you have followed Tailwind tutorials online, you may notice two different approaches to custom colours.

Older Tailwind projects commonly use tailwind.config.js:

module.exports = {
  theme: {
    extend: {
      colors: {
        brand: {
          500: '#7c3aed'
        }
      }
    }
  }
}

Tailwind CSS v4 uses the CSS-first theme approach:

@theme {
  --color-brand-500: #7c3aed;
}

This difference is important when following tutorials or migrating an existing project.

Tailwind v4's CSS-first configuration was introduced as part of the framework's move towards CSS theme variables and a more direct design-token workflow.

If a tutorial asks you to modify tailwind.config.js, check which Tailwind version it was written for before applying the instructions.

Tailwind CSS Colors and OKLCH

One of the notable changes in the current Tailwind palette is its use of OKLCH.

The official colour documentation provides the default palette in OKLCH and allows users to copy the nearest HEX value as well.

OKLCH describes colour through three components:

• Lightness
• Chroma
• Hue

A custom Tailwind colour can therefore be defined like this:

@theme {
  --color-brand-500: oklch(0.65 0.2 280);
}

The resulting theme variable can still be used through a normal Tailwind utility:

<div class="bg-brand-500"></div>

Tailwind's current theme documentation also demonstrates OKLCH values when defining custom colour scales.

Why OKLCH Matters for Colour Systems

Colour formats are not simply different ways of writing the same number.

OKLCH separates lightness, chroma, and hue, which can be useful when building or adjusting colour scales.

For a designer or developer, the practical benefit is that colour values can be worked with in a format that relates more directly to perceived changes in colour.

You do not need to calculate OKLCH values manually for every project. Modern design software and colour tools can handle conversions, while Tailwind allows the resulting values to become part of the theme.

HEX, RGB, HSL and OKLCH

You may encounter several colour formats while working with Tailwind.

Colour format	Where it is commonly useful
HEX	Brand guidelines and traditional CSS
RGB	Digital colour workflows
HSL	Colour adjustment and CSS workflows
OKLCH	Modern colour systems and current Tailwind palette values

There is no need to convert every colour into one format simply for the sake of consistency.

The important thing is that the values are accurate, supported by the project, and easy for the team to maintain.

Tailwind Colors and Accessibility

A colour being part of the Tailwind palette does not automatically make every possible colour combination accessible.

Accessibility depends on the relationship between the foreground and background.

For example:

Text: blue-700
Background: white

needs to be considered as a combination, rather than evaluating blue-700 on its own.

Important areas to test include:

• Body text
• Headings
• Links
• Buttons
• Form controls
• Focus indicators
• Alerts
• Status messages
• Icons carrying meaning
• Dark mode interfaces

Colour should also not be the only way of communicating information.

An error message, for example, can combine colour with text or another visual indicator so that its meaning does not depend entirely on colour perception.

Tailwind Colours in Dark Mode

A colour system that works on a white background may not work in exactly the same way on a dark surface.

Tailwind supports dark mode variants such as:

<div class="bg-white dark:bg-slate-900">
  <h2 class="text-slate-900 dark:text-white">
    Dashboard
  </h2>

  <p class="text-slate-600 dark:text-slate-400">
    Your latest activity
  </p>
</div>

This lets a component use different colour utilities depending on the active colour scheme.

Dark mode should be considered as part of the colour system rather than as an afterthought. Backgrounds, text, borders, links, buttons, focus states and status colours all need to remain visually clear.

How to Build a Tailwind Colour System

A practical colour system can be built in stages.

1. Identify the main brand colour

Start with the colour that represents the brand or primary action.

2. Decide which semantic roles are required

Common roles include:

Primary
Secondary
Success
Warning
Error
Information
Neutral

3. Create useful shades

You may need only a few shades for a small project, or a complete 50 to 950 scale for a larger design system.

4. Test the colours in real components

Use them in:

• Buttons
• Navigation
• Cards
• Forms
• Links
• Alerts
• Backgrounds
• Headings

5. Check contrast

Evaluate important foreground and background combinations.

6. Add the colours to the Tailwind theme

Use the approach appropriate for your Tailwind version.

7. Document the roles

If primary-600 is the main button colour, record that role so other developers know how it should be used.

This prevents a colour system from gradually turning into a collection of arbitrary values.

Common Mistakes When Using Tailwind Colors

Using one shade for everything

A single 500 shade may look fine initially, but using it for backgrounds, borders, headings and buttons can reduce visual hierarchy.

Use different shades where they have different purposes.

Creating too many custom colours

Adding a new colour every time a component needs a slightly different shade can make a design system difficult to maintain.

Before adding another colour, check whether an existing scale already provides a suitable option.

Treating the shade number as a rule

There is no requirement for 500 to be the primary colour or 700 to always be the hover colour.

The scale provides structure, not rigid component instructions.

Copying outdated Tailwind tutorials

Tailwind v4 introduced a CSS-first theme system, so older configuration examples may use a different approach.

Choosing colours without testing them

A palette can look excellent as a collection of swatches and still fail when applied to text, buttons, forms or dark backgrounds.

Always test the colours in context.

When Should You Use Custom Tailwind Colors?

Custom colours are particularly useful when a project has a defined visual identity.

You may want custom colours for:

Brand websites

A company may already have a documented brand palette.

SaaS products

Applications often need consistent primary, secondary and status colours across many screens.

E-commerce websites

Buttons, promotional elements, navigation, product labels and calls to action may need to follow a specific brand system.

Design systems

A reusable design system benefits from named colour tokens that can be shared across products.

Existing design files

If a designer has already created a palette, those colours can be translated into Tailwind theme variables.

When Are Tailwind's Default Colours Enough?

You do not have to customise Tailwind simply because customisation is available.

The default palette may be enough if:

• The project has no strict brand guidelines.
• You are building a prototype.
• The default colours already fit the interface.
• The project is relatively small.
• You want to keep the theme simple.

Customisation should solve a real design requirement rather than become unnecessary configuration.

How a Tailwind Color Generator Helps

Once you understand the 50 to 950 system, creating a custom scale becomes much easier to reason about.

Suppose your brand uses a particular purple HEX value. You may need lighter versions for backgrounds and darker versions for buttons, text, hover states, or other UI elements.

A colour generator can provide a starting point for those variations instead of requiring you to manually choose every value.

The important part is that generated colours are not automatically the final design. They should be reviewed in the context of the website, tested for contrast, and adjusted where necessary.

This is where a structured Tailwind colour workflow becomes useful: generate a scale, inspect the shades, test them in components, then add the final values to the theme.

Tailwind Colors for Designers and Developers

A shared colour vocabulary can make collaboration between designers and developers easier.

Instead of communicating a colour only as a HEX value, a team can define a role such as:

primary-500
primary-600
primary-700

A designer can use those tokens in a design system while a developer uses the matching Tailwind utilities.

For example:

<button class="bg-primary-600 hover:bg-primary-700 text-white">
  Start free trial
</button>

The class tells another developer what the colour is intended to represent, not just what visual value happens to be behind it.

That becomes increasingly useful as the project grows.

Frequently Asked Questions About Tailwind CSS Colors

What are the Tailwind colour numbers?

The current default Tailwind scale contains 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, and 950. 50 is the lightest end of the scale and 950 is the darkest.

What does blue-500 mean?

blue identifies the colour family and 500 identifies the shade within that family.

What does bg-blue-600 mean?

bg represents the background colour utility, blue identifies the colour family, and 600 identifies the selected shade.

How do I add custom colours in Tailwind CSS v4?

Use the @theme directive with a --color-* theme variable:

@theme {
  --color-brand-500: #7c3aed;
}

Tailwind can then generate utilities such as bg-brand-500 and text-brand-500.

Does Tailwind CSS v4 use OKLCH?

Yes. The current Tailwind default colour palette is represented using OKLCH values, and the official documentation also provides the nearest HEX values.

Can I use HEX colours with Tailwind?

Yes. HEX values can be used when defining custom theme colours. Tailwind's current default palette is represented in OKLCH, but custom theme variables can use supported CSS colour values.

Do all custom colours need 50 to 950 shades?

No. You can define only the shades your project actually needs. A complete 50 to 950 scale is useful when you want a flexible system that follows Tailwind's existing structure.

What is the difference between a colour scale and a colour palette?

A colour scale contains different shades of one colour family. A colour palette is the larger collection of colour families used by a design system.

Are Tailwind colours automatically accessible?

No. You still need to check the actual foreground and background combinations used in your interface.

Should I use Tailwind's default colours or custom colours?

Use the default palette when it meets your design requirements. Use custom colours when your brand or design system needs specific values or semantic colour tokens.

Is Tailwind CSS v4 different from v3 for custom colours?

Yes. Tailwind v4 introduced a CSS-first theme configuration approach using @theme, whereas many v3 projects use tailwind.config.js for theme customisation.

Final Takeaway

Tailwind CSS Colors are more useful when treated as a complete colour system rather than a list of individual colour codes.

The 50 to 950 scale provides a consistent structure for creating lighter and darker variations, while Tailwind's utility classes make those shades easy to apply across interface components.

The current Tailwind palette also gives developers a broad selection of colour families and neutral options, while Tailwind CSS v4 makes it straightforward to add, override, or replace colours through CSS theme variables.

For a project with its own brand identity, custom colour scales can make the design system more consistent. The key is to define clear roles, choose shades deliberately, test real combinations, and avoid creating colours without a purpose.

Once those decisions are made, Tailwind's colour utilities become much easier to use. Instead of asking which random HEX value belongs in a component, you can work from a colour system that has a clear relationship between shades, components and design roles.