Use an sRGB color picker on Mac for design token checks

The short answer: sample the rendered color from the UI state that will ship, copy the value in the format the token review needs, pin the approved colors, and export only the small review set. Do not treat a picker as the design system. Treat it as evidence.

TeenyColor is built for this local Mac workflow. It samples with Apple's color sampler, converts picked colors to sRGB, copies nine formats, keeps local history, supports pinned colors, and exports palettes as text or JSON.

This article is narrower than a general color-picker guide. It is for designers and developers checking whether a rendered UI color matches a design token, a semantic alias, a SwiftUI value, a CSS variable, or a token export.

Quick decision table

01Start with the exact UI state

Token names are abstractions. The screen is evidence. Open the state you actually want to check: light mode, dark mode, hover, pressed, disabled, selected, validation error, alert, empty state, or exported screenshot.

Then sample the color from that state. If the sampled value and the token value disagree, do not jump straight to changing the token. First look for opacity, aliases, state overrides, asset catalogs, browser styles, or platform defaults that explain the difference.

The matching TeenyApps hub is the Mac design token QA checklist. Use it when the review includes both the visible color and its token JSON.

02Why sRGB is the default review language

sRGB is a practical default because web colors, many app handoff notes, and common RGB or hex values can be compared without extra translation. W3C's CSS Color specs describe RGB colors in the sRGB color space for the common web color model.

That does not mean every design system should collapse into sRGB. If your team uses Display P3, OKLCH, Lab, or a strict token schema with color-space metadata, preserve that source of truth. Use an sRGB sample as the visible-screen check, not as a replacement for the system.

TeenyColor converts the sampled color to sRGB in its picker service before formatting copied values. That makes the copied value predictable for hex, RGB, HSL, CSS rgba, SwiftUI Color, UIColor, and palette exports.

03Copy the format the token review needs

A token review can fail just because the copied value lands in the wrong form. Hex works well for CSS and compact comments. RGB is easier for channel-by-channel debugging. HSL helps when hue, saturation, or lightness will be adjusted by hand. SwiftUI Color and UIColor reduce translation errors in Apple-platform prototypes.

TeenyColor supports Hex, lowercase hex, RGB, RGB decimal, HSL, HSB/HSV, SwiftUI Color, UIColor, and CSS rgba. The color-code format and precision guide documents the app’s sRGB conversion, per-format rounding, alpha handling, and the point where a source token should remain authoritative.

For token work, the rule is simple: copy the review format, not every available format. More pasted values can make a small review harder to approve.

04Use history for work in progress and pins for decisions

History is useful while you are exploring a screen. Pinned colors are for values you plan to reuse or review. Keep those roles separate.

A clean token review might have four pinned colors: current primary background, proposed primary background, current text color, and proposed text color. Name each one by role, not by mood. "Button background proposed" beats "new blue."

When the review is ready, export the small pinned set as text or JSON. The export should support the handoff note. It should not become a second design-system source.

05Keep contrast as a separate gate

A sampled sRGB value does not prove a color is usable. It only proves what you saw. Contrast needs a foreground, a background, the text size and weight, and the target threshold.

TeenyColor includes contrast checks against white and black, which is useful for quick triage. For a real UI decision, test the actual foreground and background pair. If the token touches text, controls, disabled states, alerts, or charts, make contrast part of the review note.

For broader UI evidence, use the TeenyApps Mac UI color accessibility checklist.

Ten-minute sRGB token check

1. Open the exact UI state that will ship.
2. Sample the changed foreground, background, border, and state colors.
3. Copy the value in the one format the reviewer needs.
4. Pin the current and proposed values with role-based names.
5. Export the pinned review set as text or JSON only if the reviewer needs it.
6. Check contrast separately when the color affects readable UI.
7. Write the token path, state, old value, new value, and reviewer request.

Common questions

Why use an sRGB color picker for design tokens?

sRGB gives most web and app handoffs a common value language. Sampling the rendered UI in sRGB helps compare what shipped on screen with the value stored in a token file.

Can TeenyColor export colors for token review?

Yes. TeenyColor can keep sampled colors in local history, pin review values, name colors, and export selected colors as text or JSON.

Does a sampled sRGB value prove accessibility?

No. A sampled value proves the color you saw. Contrast and accessibility still need a foreground and background pair, a target threshold, and a separate review.

Sources checked

• TeenyColor feature claims were checked against the local homepage and source files for ColorPickerService, ColorConverter, ColorListViewModel, PaletteExporter, and ContrastCalculator.
• Apple NSColorSampler documentation for the system color-sampling interface.
• W3C CSS Color Module Level 4 for sRGB color-space context in CSS color syntax.
• W3C Understanding SC 1.4.3: Contrast (Minimum) for contrast context.