Color Picker: A Practical Guide to HEX, RGB, HSL, and Contrast
A color picker is a translation tool. It takes a visual choice and expresses it as values
that browsers, design software, CSS, SVG files, and component libraries can understand. That
translation is useful when a design system needs a repeatable brand color, when a developer
needs an exact foreground value, or when a designer is comparing a proposed accent with a
background. The picker on this page keeps the basic task local to your browser: choose or
paste a color, inspect several common representations, compare it with a background, and
copy the value that the destination actually expects.
There is no universally best color syntax. HEX is compact and familiar in stylesheets. RGB
directly exposes red, green, and blue channel values. HSL makes a lightness or saturation
adjustment easier to think about. A good workflow starts with the format required by the
next step rather than converting just for the sake of converting. If a CSS variable
currently uses a hexadecimal token, copy HEX. If an animation or an alpha channel requires
component values, RGB can be more practical. If a theme needs intentional light and dark
variants, HSL can make the relationship easier to review.
Start with a Deliberate Source
Use the large color field to open your browser’s native picker, or paste a six-digit HEX
color into the input. A browser-native picker is useful for controlled selection, but it is
not a guarantee that a color viewed on one display will look identical on another. Screen
calibration, display technology, ambient light, operating-system settings, and a design
file’s color profile can all change perceived appearance. The numerical value remains
stable; the visual impression can vary. For important brand work, preserve the approved
source token and compare it in the actual destination interface.
The optional screen eyedropper button uses the browser EyeDropper API where the browser
supports it. It may be unavailable on some devices or browsers, and it requires a user
action. Treat it as a convenience rather than a required path. When it is not available,
selecting a color manually or pasting a known value gives the same reliable conversion
result.
HEX Values Explained
A six-digit HEX value begins with a hash sign and contains three two-character pairs. The
first pair represents red, the second green, and the third blue. Each pair ranges from 00 to
FF in hexadecimal notation, which corresponds to 0 through 255 in decimal channel values.
For example, #EF6C54 has a strong red channel, a midrange green channel, and a
lower blue channel, producing a warm coral tone. Short three-digit HEX notation can
represent repeated pairs, but this page writes a full six-digit value so the copied output
is explicit.
HEX is a strong default when a static CSS color token is needed. It is short, readable to
many developers, and widely supported. It does not communicate the perceptual relationship
between two shades particularly well, however. Two colors with nearby HEX values can still
look quite different, especially around dark values. Use a visible comparison rather than
relying on character similarity in a code review.
RGB and HSL for Different Editing Jobs
RGB describes a color as separate red, green, and blue intensities. It maps naturally to the
display model used by many screens. An RGB value such as rgb(239, 108, 84) is
also a convenient starting point for rgba() or modern CSS alpha syntax when an
interface needs translucency. Channel-by-channel edits are precise, but they are not always
intuitive. Increasing all three values can make a color lighter, although the perceived
result depends on the original hue.
HSL separates hue, saturation, and lightness. Hue moves around a 360-degree color circle;
saturation controls intensity; lightness controls the perceived balance between black and
white. A team building hover states, disabled states, or a family of related tags may find
HSL easier to inspect because it exposes those editing intentions. It still deserves testing
in the final interface. A mathematically lighter color may not provide enough contrast
against a nearby surface, and a highly saturated accent can create glare even when a ratio
passes.
Contrast Is a Readability Check, Not a Complete Accessibility Audit
This page calculates the contrast ratio between the selected foreground and a second
background color. The result is compared with common WCAG contrast thresholds: 4.5:1 for
normal text at AA, 3:1 for large text at AA, 7:1 for normal text at AAA, and 3:1 for large
text at AAA. WebAIM also describes a 3:1 threshold for graphical objects and user-interface
components. These numbers are useful design checks, but they do not prove that an entire
page, component, document, or product is accessible.
Readable content depends on more than a color pair. Font size, weight, line length, spacing,
focus indicators, icons, zoom behaviour, hover-only information, and the user’s device all
matter. Treat a passing result as one review signal. Test the actual component with its real
text, state changes, borders, and interaction. If text is on a photo, gradient, video, or
translucent surface, the measured flat-color ratio may not describe what a reader sees
across the whole area.
A Repeatable Palette Workflow
When building a palette, begin with roles rather than a long list of unrelated attractive
swatches. A small system might include page background, surface, primary text, secondary
text, border, primary action, action hover, status success, warning, and danger. Choose an
approved anchor color, then create intentional variants for each role. Save useful choices
to the history row and revisit them against the actual background. The history exists for
comparison and convenience; it is stored only in the current browser session on this page
and should not be treated as a long-term design library.
For a brand handoff, copy labels as well as values. A token named
--brand-coral is easier to maintain than a scattered raw value pasted into ten
components. Keep a source of truth in the project where the team works, such as a CSS
variables file, a token JSON file, or a design-system library. A picker helps identify and
convert values; it does not resolve design governance or version control.
Using Picked Colors in CSS
CSS accepts several color syntaxes. A basic declaration can use
color: #172437;. A component may use
background: rgb(239, 108, 84);. A theme can use hsl(10 81% 63%) if
the project’s browser support requirements allow it. Keep syntax consistent inside a
codebase where possible. Consistency makes reviews easier and avoids accidental visual
differences caused by rounding, alpha treatment, or duplicated tokens.
Do not paste a color into a sensitive context without checking its purpose. A marketing
accent can be vibrant. Body text, form labels, and error messages need predictable
readability. Color should not be the only way to convey a result: pair success with a clear
label or icon, pair an error with explanatory text, and give interactive controls a visible
focus state. Those choices help people who cannot reliably distinguish every hue and people
working in bright, dim, or low-quality display conditions.
From Image Sampling to Production Tokens
Sampling an image can be useful for inspiration, but an image pixel is not automatically a
usable interface token. It may be affected by lighting, compression, transparency, a blend
mode, or a nearby pixel. Start with a sample, then adjust it deliberately and test it in the
page context. A thin coral line may look lively on ivory yet disappear at small sizes; a
navy label may look authoritative but need a lighter surface behind it. Use the sample as
input to a design decision, not as a final decision by itself.
If a source image includes a logo or brand asset, check the organisation’s official
guidelines before using the sampled value in a public interface. Small changes in conversion
or image export can create near-matches that are not actually approved colors. The exact
approved token, if available, is better than an approximate screen sample.
Why Color Values Sometimes Look Different
Two displays can show the same HEX value differently because displays have different gamuts,
calibration profiles, brightness, and colour-management behaviour. A phone used outdoors may
make a pale colour appear washed out; a high-saturation display can make an accent feel
stronger than intended. This is normal. Web color syntax describes values for the rendering
system, not a promise of identical physical light output. Review priority interfaces across
a representative phone, laptop, and desktop setup when visual accuracy matters.
Transparency adds another layer of context. A semi-transparent foreground blends with
whatever is beneath it. If the background can change, evaluate the resulting range rather
than one sample. This is why solid backgrounds and explicit focus styles are often safer for
form controls and text than a translucent overlay on an unknown image.
Useful Checks Before You Copy
Confirm that the input is valid, decide which syntax the destination accepts, inspect the
contrast result with the real background, and copy one canonical value. If you are updating
a design system, record the role as well as the color. If you are updating CSS, search the
project for duplicated near-matches before adding another raw value. If you are matching a
brand, verify the official source. These small checks reduce accidental visual drift and
make later maintenance easier.
Toolyfi’s Color Picker is designed for quick client-side conversion and comparison. It does
not upload a chosen value, create a permanent account, or certify a complete accessibility
review. Use it to make a clear local decision, then verify the result where it will actually
be seen.
Building States, Not Just One Attractive Swatch
An interface rarely uses a color only once. A button can have default, hover, focus, active,
disabled, loading, success, and error states. A single brand accent therefore needs
companion decisions. Start by deciding the job of each state. A hover state should still be
recognizable as the same action. A focus state should remain visible against every permitted
surface. A disabled state should not look like a failed state. This page can help inspect
candidate values, but the states should be tested together in the component rather than as
isolated chips.
For text and controls, keep roles separated. Primary text, secondary text, muted helper
text, link text, border color, and selected-state color can all need distinct values even if
they look similar in a mockup. When values are too close, small display differences or
low-quality projectors can erase the intended distinction. When values are too far apart, a
product can feel visually noisy. A palette is a set of relationships, not simply a
collection of favorite individual colors.
Light and Dark Surfaces Need Independent Review
Do not assume that a foreground which works on an ivory surface will work on a navy surface,
or vice versa. In a system with light and dark modes, evaluate each semantic token against
each surface it can occupy. A pale neutral may work for quiet borders on light mode but
disappear in dark mode. A saturated coral action may be energetic on ivory while creating
glare on a dark panel. The contrast checker can test pairs quickly; a complete component
review reveals whether the hierarchy still makes sense.
Some teams try to obtain dark-mode tokens by merely inverting light-mode values. That
shortcut often produces unexpected saturation and hierarchy. It is better to begin from the
intended role—such as readable body text, quiet elevated surface, or high-emphasis
action—and tune the value for the actual background. Store those values under meaningful
names and document which mode and role they belong to.
Rounding, Conversion, and Source Consistency
Color models convert between continuous and discrete values. An HSL representation is
commonly rounded for easier reading, while the underlying RGB channels are integers for an
ordinary sRGB HEX value. Converting a rounded HSL value back to RGB can sometimes produce a
nearby rather than identical token. For routine CSS work this is often harmless, but it
matters when a system requires an exact approved brand value. Keep the original approved HEX
or RGB token as the source of truth, then treat other displayed representations as useful
views of that same choice.
Likewise, do not copy a color from one tool, adjust it in another, and assume it has stayed
unchanged without verifying the final field. Design software may display color profiles,
alpha settings, or alternative formats that a basic web value does not encode. When handing
off an important palette, include the concrete format required by the implementation and a
visual reference in the target environment.
Practical Review Checklist
Before shipping a color change, ask four simple questions. First, is the token connected to
a defined role? Second, does the foreground/background pair remain readable at the actual
font size and weight? Third, is there another cue besides color for critical status or
interaction? Fourth, have the relevant light, dark, hover, focus, and disabled states been
viewed on a real device? These questions are faster than repairing an unclear form or
inaccessible alert later.
Use the picker as part of that loop: enter a starting value, copy the format your codebase
uses, compare the critical pair, preserve useful candidates in the session history, then
validate in the destination. The output is immediate, but the decision should remain
deliberate.
Why OKLCH Is Useful for Modern Design Tokens
OKLCH is another way to describe a color. Its three values describe lightness, chroma, and
hue. The practical reason to inspect it is not that every project must immediately rewrite
its palette. It is that lightness can be easier to reason about when a team needs related
surfaces, readable text, or a systematic scale around a brand accent. The value shown by
this page is a calculated view of the selected sRGB color; it is not a promise that every
browser, design tool, or older project workflow accepts the same syntax.
Keep the format that the destination actually supports. A component library may use HEX
tokens, a CSS build may use HSL, and a newer design system may intentionally use OKLCH. The
useful practice is to preserve one approved source value and document how derived values are
used. Do not create a family of near-identical values simply because several formats are
available. A palette becomes easier to maintain when each token has a role and a clear
owner.
Contrast Ratios Need Context
A contrast ratio measures the relative luminance difference of two solid colors. That makes
it a useful early check for foreground text and a flat background. It does not account for a
background photograph, image compression, an alpha overlay, texture, a changing hover state,
or text that moves over a video. Where a surface varies, test the weakest visible portion of
the actual component. A ratio that passes in a blank test box can still fail for a reader
when the production background is lighter, busier, or partially transparent.
The ratio also does not decide hierarchy by itself. A page can technically pass one
threshold yet make labels, helper text, alerts, and buttons difficult to scan because every
element has similar emphasis. Use contrast as a safety boundary and use type scale, spacing,
labels, borders, icons, and focus treatment to make the interface understandable. Critical
feedback should never depend on a hue change alone. A success state needs a readable word or
symbol; an error needs a direct explanation and a path to correct it.
Build Palette Scales Around Roles
A practical palette begins with questions rather than swatches. Which color is the page
surface? Which is the default text? Which supports a quiet border? Which calls attention to
a primary action? Which indicates a destructive action without being confused with the brand
accent? Once those jobs are named, create only the variants the interface actually needs.
Review each one beside the surfaces and states where it will appear. This avoids a common
problem in which an attractive isolated color is copied into text, buttons, graphs, and
warnings even though those roles need different contrast and emphasis.
Teams can make this review repeatable by recording a compact table of token name, intended
role, approved value, permitted surfaces, and contrast notes. The record can live in a CSS
variables file, token repository, component documentation, or design library. When a brand
value changes, an explicit role map makes it possible to find all affected components. A
color picker helps produce and compare the values, but a documented token system prevents
visual drift over time.
A Handoff Checklist for Color Decisions
Before handing a color decision to another person, include the exact value, the syntax they
need, the semantic role, the intended background, and a screenshot or component reference.
Mention whether the value is solid or uses alpha. If it belongs to dark mode, say so
clearly. If the color was sampled from an image, state whether it has been approved or is
only a working candidate. These details prevent a later implementation from silently turning
a decorative sample into body text, a control border, or a status signal.
Finally, view the finished component at normal and enlarged zoom on the actual devices your
audience uses. A useful color choice is one people can read, navigate, and understand in its
real context—not merely one that looks good in a picker. Toolyfi provides immediate local
values and contrast arithmetic so that review can begin quickly. The final decision remains
a product and accessibility responsibility that belongs in the destination experience.
Transparency Requires a Separate Check
A solid HEX value is only one layer of a final visual result. If a component uses opacity,
the visible color is a blend with its current background. Test the actual blend over every
surface that component can use, then document the alpha value together with the base token.
This prevents a readable label from becoming faint when the surface changes.
Toolyfi
