How to choose a disabled button color in a UI

A disabled button should look unavailable, but its label still needs to be easy to read. If it looks too much like an active button, people may keep clicking it. If it fades too far into the page, they may not know the button is there.

You can compare colors against your actual interface instead of guessing from a color chart. The Color Picker samples colors from your screen and shows their HEX, RGB, and HSL values.

Choose and compare a disabled color

1. Open the Color Picker on a computer in Chrome or Edge. Other browsers may provide a reduced version or no screen sampling. Display your design, prototype, or page on screen.
2. Sample the page or panel behind the button, then sample the enabled button’s fill and label. Note the HEX values so you can return to them.
3. In your design tool or code, make a disabled version of the button. Try a less saturated fill and a darker, still-readable label. Avoid changing the whole button to a very low opacity, since the result depends on whatever is behind it.
4. Show the enabled and disabled versions next to each other on the same background. Check them at their actual size, then sample the revised colors if you want to record their values.

The Color Picker samples what appears on screen. It does not create a disabled state or tell you whether a color combination meets accessibility requirements, so use it to compare your own design rather than as a pass-or-fail check.

Choose a color treatment that reads clearly

Use a quieter fill and a readable label

A common starting point is a pale neutral fill with a medium-dark label. For example, try a fill of #E5E7EB with a label of #4B5563 on a white interface. These are starting values, not a rule. Your brand colors, font size, and surrounding surfaces can change how the button looks.

Keep the label close to the normal text color rather than making it nearly white. A button can appear inactive because its fill is less vivid and it has no active-state shadow, while the words remain legible. Sample the label and fill separately so you can adjust one without unnecessarily fading the other.

Keep the change consistent with your design

If your enabled button is bright blue, you might use a muted blue-gray for its disabled fill rather than switching to a color that has no connection to the rest of the interface. If your interface uses neutral buttons, a lighter neutral fill and a subdued border may fit better. Apply the same approach across similar buttons so users learn what the state means.

Make the state clear without color alone

Color should not be the only clue that a button is disabled. Keep its label visible, remove hover or pressed effects that imply it can be clicked, and explain what needs to happen when that would help. For example, place a short note near a disabled Continue button explaining that required fields are missing.

Check the button in context

A color that looks distinct in a palette can disappear when used at small size. Check the button on the real page background, beside nearby controls, and at the size people will see it. If your interface has light and dark themes, check both separately. A color sampled from a light surface may not work on a dark one.

Also check the button without relying on hover. Touchscreen users do not hover, and someone using a keyboard may move focus without a mouse. The inactive appearance should be understandable in the normal page view, not only after a pointer moves over the control.

For a concrete comparison, put the enabled and disabled buttons side by side. Ask someone who has not seen the design to identify which one is unavailable. If they mistake the disabled button for an active one, make the difference more noticeable. If they can barely read its label, darken the label before making the fill stronger.

Adjust a disabled button that is hard to understand

1. Darken the label. If the words are difficult to read, keep the muted fill and choose a darker text color. Do not assume that fading the entire button is the only way to show its state.
2. Increase the difference from the enabled state. Reduce the fill’s saturation or brightness, or use a quieter border. Change one feature at a time, then compare the two states on the same surface.
3. Add a nearby explanation. If people cannot tell why the button is unavailable, state what they need to do, such as selecting an option or completing a required field.
4. Check the control’s actual disabled behavior. In a website, use the appropriate disabled state in the interface, not only a gray appearance. Make sure keyboard and assistive technology users can tell whether the control is available.

What accessibility contrast rules mean

WCAG excludes inactive user interface components from some minimum contrast requirements. That exception does not mean disabled text should be unreadable or that the disabled state should be difficult to recognize. A person may need to read the button label to understand what action is unavailable.

There is no single disabled-button color that works for every design. Keep the label legible, make the inactive state distinct in context, and use a clear explanation when the reason is not obvious.