Perceived brightness calculator

It uses the familiar weighted RGB formula that gives green the greatest influence, red the next greatest, and blue the least. The result is classified as light or dark against a documented threshold, then paired with a suggested black or white text color. Use it when a theme, badge, chart, or user-selected background needs an immediate and repeatable foreground choice.

Why perceived brightness uses weighted RGB channels

A simple average treats red, green, and blue as if human vision responded equally to each channel. It does not. Green contributes much more to the brightness people perceive, red contributes a moderate amount, and blue contributes less. This calculator therefore applies the classic BT.601-style luma weights: 0.299 for red, 0.587 for green, and 0.114 for blue. Each channel must be an integer from 0 through 255. The weighted values are added to produce a score on the same approximate 0-to-255 scale, where black is zero and white is 255. The returned score is rounded to three decimal places so results remain readable while preserving useful precision. This operation is deterministic: identical RGB inputs always produce identical output, with no color profile lookup, network request, random choice, or device-specific adjustment. The calculation is especially useful for interface decisions that need a fast, understandable estimate rather than a complete color-management or accessibility analysis.

How the light or dark classification chooses text

After calculating perceived brightness, the capability compares the score with a threshold of 128. A score at or above 128 is classified as light, while a score below 128 is classified as dark. For a light background, the response recommends black text; for a dark background, it recommends white text. The output includes the original channels, the precise brightness score, the classification, the recommended text color, the threshold, and the formula, so an application can store or audit the decision instead of relying on an undocumented boolean. The boundary is intentionally explicit: a score of exactly 128 belongs to the light class. This makes behavior predictable around the cutoff and avoids slightly different results across clients. The recommendation is a convenient binary foreground choice for labels, chips, generated avatars, and theme previews. It is not a claim that every font size or visual treatment meets a particular accessibility standard; use a contrast-ratio checker when formal conformance is required.

Validate channels and use the result safely

Send the RGB components as the r, g, and b fields. Every field is required, must be numeric, must be a whole integer, and must remain within the inclusive range from 0 to 255. Values such as -1, 256, a fractional channel, a numeric string, NaN, or a missing field are rejected as invalid input rather than clamped silently. Strict rejection matters because clamping can hide upstream conversion bugs and make a saved design differ from its preview. Once a valid response arrives, use classification when only a light-or-dark branch is needed, or use recommended_text_color directly when the interface accepts a hexadecimal foreground. Use perceived_brightness when sorting swatches or exposing the calculation to users. The API costs $0.002 per request, while the deterministic browser path can run the same calculation locally. For large palettes, call the calculation once per color and retain the result alongside the source RGB values so later rendering does not need to guess how the decision was made.