Color Picker From Image: Build an App Palette

A color picker from image should produce five to eight named app roles, not every hex code visible in the screenshot. Sample one dominant surface, one supporting surface, one brand primary, and one deliberate accent; then apply the 60-30-10 distribution to backgrounds, surfaces, and emphasis. Name each value by function—such as background, surface, primary, and on-primary—and test every text-on-surface combination against WCAG 2.2 AA before creating separate dark-mode role values.

Key takeaways

•Use the 60-30-10 heuristic: 60% background, 30% surfaces, 10% primary or accent emphasis.
•WCAG 2.2 AA requires 4.5:1 contrast for normal-size text.
•Large text may use 3:1 contrast under WCAG 2.2 AA.
•Material Design 3 names functional roles such as primary, on-primary, surface, and on-surface.
•iOS dynamic colours and Android DayNight themes require role-based light and dark values.

This guide is for mobile UI/UX designers, founders, and engineers who can inspect a reference screenshot and work with design tokens or platform colour resources.

Time: 25 minutes · You'll need: A reference app screenshot at its original resolution, Figma desktop with the Eyedropper tool, or an image editor with a pixel-level eyedropper, A WCAG 2.2 contrast checker, A token sheet with role names and light/dark columns

What's on this page

•Sample the colours that define the screen
•Map the app color palette to 60-30-10
•Assign roles instead of retaining raw hex values
•Check each text-on-surface pair before commit
•Create a dark counterpart for each role
•Reference table

•Common mistakes
•FAQs

Build an app color palette from a screenshot

1. Sample the colours that define the screen

Place the screenshot on a canvas at 100% scale. Use the eyedropper on large, flat regions first: the page background, the most common card or container surface, the main branded control, and one high-attention accent such as a status chip or selected state. Take three samples from each large area. If the values differ because of compression, gradients, shadows, or antialiasing, choose the value from the centre of the flat area rather than an edge pixel.

Do not extract colors from image decoration indiscriminately. A screenshot can contain 30 or more pixel colours from photographs, shadows, illustrations, and text antialiasing, but a first-pass mobile palette needs only five to eight functional candidates. Record each sample with its screen location, for example card centre or primary button fill. The result should be a short candidate list: background, surface, primary, accent, dark text, and light text—not a swatch dump.

Tip: Avoid sampling a 1 px border or shadow; it often exists only to separate adjacent surfaces and is not a reusable app colour.

2. Map the app color palette to 60-30-10

Use 60-30-10 as a composition heuristic, not as a requirement from Apple or Google. Assign roughly 60% of visible screen area to the least prominent background role, usually the app canvas. Assign roughly 30% to surfaces: cards, sheets, grouped list rows, input containers, and bottom navigation containers. Reserve about 10% for attention: primary buttons, selected controls, progress, links, and a restrained accent.

Measure area by what the user sees on a typical screen, not by counting tokens. A checkout screen with a full-width primary button can still fit the rule because the button occupies little total area. If the screenshot has a photo or editorial illustration, exclude that asset from the distribution; its colours do not automatically become UI colours. Build a simple swatch board with three labelled columns—60 background, 30 surface, 10 emphasis—and move each candidate into one column. If two bright candidates compete in the 10% column, retain one as primary and reserve the other for a documented semantic state.

Tip: A bright accent used on every card stops functioning as an accent; move repeated decoration into a quieter surface treatment.

3. Assign roles instead of retaining raw hex values

Turn each selected value into a role that explains where it may appear. Start with background for the app canvas, surface for elevated or grouped containers, primary for the main actionable brand colour, on-primary for content drawn over primary, on-surface for standard text and icons on surfaces, and outline for boundaries when needed. Keep the original sampled hex value beside the role only as a source record.

This naming matches the role-based model used by Material Design 3, including primary, on-primary, surface, and on-surface. It also translates cleanly to Apple semantic colours, where the consuming view asks for a purpose rather than a fixed appearance. Do not name a token blue-500 if it is the only primary action colour; a later rebrand would make the name false. Create a light-mode token table now, with one role per row and a short usage rule. The working result is a palette that a designer can apply to screens and an engineer can map to iOS asset colours or Android theme resources.

Tip: Keep status colours such as error separate from the screenshot-derived brand accent; success, warning, and error need their own tested text pairs.

4. Check each text-on-surface pair before commit

Test every pair where text or an icon communicates information over a fill: on-background on background, on-surface on surface, on-primary on primary, plus text inside selected chips, banners, and disabled-looking controls. WCAG 2.2 Success Criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text at Level AA. Large text may use 3:1; WCAG defines large-scale text as at least 18 point regular or 14 point bold.

Enter the exact foreground and background values into a contrast checker. Do not check a text token against white if the screenshot places it on a tinted card. Check the actual composited colour when a translucent surface, image scrim, or overlay sits behind text. Also check icons and control boundaries that convey state: WCAG 2.2 Success Criterion 1.4.11 sets a 3:1 minimum for non-text UI components and graphical objects where contrast is required. Replace a failing sampled value with an adjusted role value, then retain the screenshot value only as reference evidence.

Tip: A brand primary can remain unchanged while on-primary changes from white to a near-black; test both before assuming white text is correct.

5. Create a dark counterpart for each role

Make a second value for every role that appears in light mode: background.dark, surface.dark, primary.dark, on-primary.dark, and on-surface.dark. Do not invert the screenshot or merely swap black and white. Dark interfaces need distinct surface separation, readable text, and contrast-tested emphasis; a light card colour inverted mathematically can become a glaring panel or erase hierarchy.

Keep the role names and component usage rules identical across modes. Only the values change. On iOS, dynamic colours resolve according to the current interface style through trait collections. On Android, a DayNight theme supplies different resources for light and dark configurations. Test the same representative screen in both appearances, including selected navigation, primary actions, cards, modal sheets, and status messaging. Re-run the WCAG checks using the dark background and surface values because a pair that passed against a light surface may fail when the foreground is softened for dark mode. Your completed output should contain parallel light and dark token columns, ready for native mapping.

Tip: Do not use pure black by default; choose the dark background and surface values from tested role relationships, then validate their visible separation on an actual device.

Reference table

WCAG 2.2 AA contrast thresholds

Content type	Minimum ratio	Applies to
Normal text	4.5:1	Level AA minimum
Large text	3:1	18 pt or 14 pt bold
Non-text UI	3:1	Required visual indicators

Do it with the free Color Picker from Image

Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.

Open the Color Picker from Image → — free, no sign-up.

Common mistakes

Sampling every visible pixel colour from the screenshot.

Sample large flat background, surface, primary, and accent regions first. Treat image, shadow, and antialiasing colours as asset or rendering data unless a component needs them.

Naming tokens after hue, such as purple-600.

Name the token by UI function, such as primary or surface. Preserve the sampled hex in documentation, not in the functional token name.

Checking dark text against white instead of the actual card surface.

Test each foreground against the exact fill behind it. A tinted card, bottom sheet, or translucent overlay changes the contrast result.

Generating dark mode by colour inversion.

Create a dark value for each role and test the same screen states. iOS dynamic colours and Android DayNight themes work best when semantic roles remain stable.

Frequently asked questions

How do I use a color picker from image without copying every colour?

Use a color picker from image to sample only the background, repeated surface, primary action, and one accent before assigning functional roles. Take samples from flat centre areas rather than shadows, borders, photos, or antialiased text. A working mobile palette usually begins with five to eight role candidates, not the full set of pixel colours.

What is the 60-30-10 rule for an app color palette?

The 60-30-10 rule is a visual distribution heuristic that assigns about 60% of a screen to background, 30% to surfaces, and 10% to emphasis colours. Use the 60% area for the canvas, the 30% area for cards and containers, and the 10% area for primary actions, selected states, and restrained accents. It is not an Apple, Android, or WCAG requirement.

How do I extract colors from image and make them accessible?

To extract colors from image accessibly, test every actual foreground-background pair against WCAG 2.2 AA before using it in a component. Normal text requires 4.5:1 contrast, while large text may use 3:1. Check text on the exact card, sheet, button, or tinted surface where it will appear, not against a default white background.

What roles should a mobile UI color generator produce?

A mobile UI color generator should produce semantic roles including background, surface, primary, on-primary, on-surface, and outline rather than unnamed hex values. Add separate semantic roles for error, success, and warning when the app communicates those states. Material Design 3 uses this role-based approach so components can change appearance without changing their purpose.

Do I need a separate dark palette if I copied a light screenshot?

Yes, a palette copied from a light screenshot needs separate dark-mode values for every role used by the interface. Keep names such as surface and on-surface stable, but choose new values that preserve hierarchy and meet contrast requirements. iOS dynamic colours and Android DayNight themes can then resolve the appropriate values for the current appearance.

Where this leaves you

A screenshot is evidence of a visual system, not a token file. Sampling only the dominant background, supporting surfaces, primary action colour, and controlled accent prevents decorative pixels from becoming permanent product decisions. Functional names make the palette portable across iOS and Android, while WCAG checks prevent a visually faithful sample from creating unreadable controls. A separate dark palette preserves those same roles when the operating system changes appearance. Take one representative screenshot now, create the light and dark role table, and validate every text-on-surface pair before handing values to engineering.

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

•Contrast Checker — Test any pair against WCAG 2 and the newer APCA method, with a colour-blind check and the nearest passing colours.
•Colour Blindness Simulator — See your screens through every type of colour vision deficiency at once, and download the whole comparison.
•Dark Mode Color Generator: Mobile App Guide — Use a dark mode color generator workflow to derive mobile app tokens, tonal elevation, mut
•Contrast Checker: Meet WCAG in Mobile Apps — Use a contrast checker to audit WCAG 2.2 mobile text, controls, placeholders and states, t
•Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery