Calculate WCAG relative luminance and perceived brightness for any HEX color. Check color lightness for contrast, accessibility, and UI design.
Tell us more, and we'll get back to you.
Contact UsCalculate WCAG relative luminance and perceived brightness for any HEX color. Check color lightness for contrast, accessibility, and UI design.
Enter a HEX, RGB, or HSL value. Inputs stay synchronized.
Choose a second color to test as foreground or background.
Share the current inputs or ask ChatGPT to explain the calculation in context.
Color brightness and luminance are fundamental concepts in color theory and digital imaging that describe how light or dark a color appears to the human eye. While these terms are often used interchangeably, they represent different aspects of color perception and measurement.
Each method has its own specific use case and advantages:
Where R, G, B are color channel values (0-255), and R', G', B' are gamma-corrected values
Our understanding of color and luminance has evolved dramatically since Isaac Newton's groundbreaking experiments with prisms in 1666. The field took a major leap forward in the 1920s when the International Commission on Illumination (CIE) developed standardized color spaces and measurement techniques. Today, digital color science combines physics, psychology, and computer science to create precise methods for measuring and reproducing color experiences.
RGB values are device code values, not direct measurements of perceived lightness. A color with red 255, green 0, and blue 0 does not look as bright as a color with red 0, green 255, and blue 0, even though both have one channel at maximum. Human vision is more sensitive to green wavelengths than to red or blue. Brightness formulas use different weights and transformations to model that sensitivity for different purposes.
The simple average treats red, green, and blue equally. It is easy to calculate, but it often disagrees with human perception. Luma formulas, such as Rec. 601, use weighted channel values that were designed for video systems. They are useful in image processing and broadcast contexts, especially when converting color information into a brightness-like signal. Perceived brightness formulas often use squared channel values and a square root to better approximate how bright a color feels to viewers.
WCAG relative luminance follows a more specific process. It first linearizes sRGB channel values because screen code values are gamma encoded. Then it applies coefficients that reflect standardized color matching data. This matters for accessibility because contrast ratios should be based on a consistent model, not on a rough average. A color pair that looks acceptable by simple average may fail a WCAG contrast check after gamma correction and relative luminance are applied.
The calculator is therefore most useful when the method matches the decision. Use WCAG relative luminance when checking text contrast, interface compliance, and accessible color palettes. Use luma when working with video workflows or grayscale conversion. Use perceived brightness when making design judgments about how light or dark a swatch feels. Use the average only for quick sorting or simple programmatic tasks where precision is not important.
In interface design, luminance should be tested in context. Text size, font weight, background pattern, antialiasing, display brightness, and viewing environment all influence readability. A contrast ratio that barely passes may still feel weak for thin text or outdoor viewing. A stronger contrast margin gives the design more resilience across monitors, phones, projectors, and user settings. The calculator can identify risky color pairs early before they become part of a larger design system.
Color meaning should not rely on brightness alone. Error states, success states, chart series, maps, and status badges are easier to understand when luminance contrast is paired with labels, icons, patterns, or shape differences. This helps users with low vision, color vision differences, monochrome printing, and poor display conditions. Luminance numbers can guide the palette, while redundant cues make the interface easier to use.
Screens also vary. An OLED phone, a budget laptop panel, a calibrated design monitor, and a conference room projector can render the same RGB values with different apparent brightness. Ambient light can wash out dark colors and reduce perceived contrast. This does not make calculations useless. It means the calculator should be used as a baseline, followed by practical testing on the devices and environments that matter most.
For image processing, luminance can support thresholding, edge detection, automatic captions over images, histogram analysis, and color sorting. The right formula depends on whether the task is about human readability, legacy video compatibility, or computational speed. Documenting the chosen formula prevents confusion when two tools report different brightness values for the same color. Different answers may all be correct within their own definitions.
Color calculations should start by confirming the input format. Hex colors, RGB integers, normalized RGB values, HSL, HSV, and display color spaces do not store information in the same way. A formula written for 0 to 255 sRGB values should not be applied directly to percentages or linear-light values without conversion. The calculator handles its expected input, but developers should document the format when copying results into code.
Alpha transparency changes the final visible color. A semi-transparent foreground over a background must be composited before luminance or contrast is evaluated. Testing the foreground color alone can give the wrong answer because the actual displayed color is a blend. This matters for overlays, disabled buttons, shadows, glass effects, and text placed over images.
Gradients and images need sampling rules. A text color may pass contrast over one part of a background and fail over another. For image-backed cards, test the darkest and lightest likely areas or add a solid overlay that creates a predictable luminance range. A single average background color can hide local contrast failures.
Design tokens help keep luminance decisions consistent. Once a palette has approved foreground and background pairs, store those pairs instead of recalculating from memory. Tokens can identify primary text, muted text, borders, focus rings, warnings, and disabled states. This reduces the chance that a later color change accidentally breaks readability.
Automated checks are helpful, but visual review still matters. Thin fonts, small text, low-quality displays, and bright ambient light can make a mathematically passing pair feel weak. Aim for a margin above the minimum when the component is important, used outdoors, or read by a wide audience. The calculator gives an objective value, and practical review checks the human experience.
First, choose the formula that matches the task. Accessibility checks need WCAG relative luminance. Video processing may need luma. Human-centered palette sorting may use perceived brightness. A mismatch between formula and task is the main reason two tools appear to disagree.
Second, test the actual color pair. A foreground color that works on a plain background may fail over a gradient, image, or translucent layer. Composite transparent colors before calculating luminance, then test the lightest and darkest likely background areas.
Third, keep enough contrast margin for real conditions. Minimum ratios are thresholds, not comfort guarantees. Small text, thin strokes, glare, dim projectors, and low-quality screens all benefit from stronger contrast than the minimum.
Match the formula to the task, test the actual foreground and background, and leave contrast margin for real screens.
Luminance is the objective, measurable intensity of light emitted by a surface, while brightness is the subjective perception of that luminance by the human eye. The human eye is more sensitive to green light than red or blue, which is why different calculation methods use different weights for RGB channels. WCAG luminance is specifically designed for accessibility standards, while perceived brightness better matches human visual perception.
Choose based on your needs: Use WCAG Relative Luminance for accessibility compliance and contrast calculations. Use Perceived Brightness for design decisions that match human perception. Use Luma for video and broadcast applications. Use Simple Average when you need a quick approximation or when precise values aren't critical. For web accessibility work, always use the WCAG method as it's the standard for compliance.
This occurs because human eyes are more sensitive to green light (around 555nm wavelength) and less sensitive to blue light. For example, a pure green (#00FF00) appears brighter than a pure blue (#0000FF) even though they have the same RGB average. This is why weighted formulas like perceived brightness and WCAG luminance give more weight to green (0.587 or 0.7152) and less to blue (0.114 or 0.0722).
sRGB color values are gamma encoded, so the numeric channel values are not linear light measurements. WCAG converts them to linear values before applying luminance coefficients, which produces a more consistent basis for contrast ratios.
Yes. Hue, saturation, surrounding colors, display settings, and adaptation can change perceived brightness. Luminance is a standardized measurement, while visual perception also depends on context.