Picking a Colour From the Screen in a Web App: A Sample Is Not an Approved Brand Colour

Offer screen colour sampling as an optional shortcut for filling a colour field, not as the only way to complete a design request. Show the chosen value, let the person correct it and keep project approval separate. Sampling a pixel should not immediately change every branded page or confirm a production order.

A small artwork-request portal might let a customer point at a colour in a reference image. That can communicate an initial preference. If the customer already has an approved colour code or artwork specification, give them a direct way to supply it rather than forcing them to sample a screen.

Name the value you are collecting

Chrome's EyeDropper documentation explains that a selected pixel produces an sRGB hexadecimal value in the form #RRGGBB. Specify that meaning beside the field and in the saved record. A field called only “colour” leaves the next person guessing what kind of reference they received.

The source describes a screen-pixel value. It does not promise a match to an approved brand palette, a physical material or printed output. Do not turn the convenience feature into that promise. If production needs another colour system or a supplier's physical sample, agree that handover separately with the responsible specialist.

For a hypothetical artwork request, store the sampled value as “requested screen colour” until the person responsible for the design approves it. This is a workflow recommendation, not an API feature or an assertion that the browser checks brand guidelines.

Make sampling a deliberate temporary mode

The documentation says opening the eyedropper requires a user action, such as a button click. The browser then makes the mode visible, and a colour is returned only after the person selects a pixel. This is not a facility for silently reading the screen in the background.

Use a clear action such as “Pick a colour from the screen.” Explain that Escape cancels. The documented selection promise is rejected when the person leaves that way, so cancellation needs a normal interface outcome rather than a frightening generic failure message.

Our recommended behaviour is to keep the previous field value unchanged on cancellation. After a successful selection, update a preview and the visible code, but leave the form unsaved until the agreed save action. A preview swatch should accompany the text value, not replace it.

Keep a usable route when sampling is unavailable

Chrome's guide explicitly tells developers to check whether the API is available before using it. Do not infer support on all customer phones or browsers from a successful desktop demonstration. Ask for the actual supported browser and device set to be listed and tested.

Provide manual code entry and any agreed palette choices independently of the eyedropper. Someone who cannot use screen sampling should still be able to submit the request. State what code format the manual field accepts, validate it and explain corrections in words. Those are application requirements; feature detection alone does not build them.

The guide also describes application cancellation when the app's state changes substantially. In your specification, define what happens if the customer leaves the request, changes the target item or opens another important interaction while sampling. An old selection must not be applied to a different item's colour field.

Demonstrate the value reaching the right request

Ask for a harmless test image and invented request records, then check:

• The eyedropper starts only after the explicit action.
• A selection shows its code and preview against the intended field.
• Escape retains the previous value without saving a change.
• Changing the target item cannot apply a late result to the wrong item.
• An unavailable eyedropper leaves manual entry and submission usable.
• Reloading a saved request shows the same code and its provisional or approved status.
• Final design approval remains a separate recorded action.

These checks concern your agreed workflow. They do not certify colour reproduction or accessibility. Put the device coverage and expected outcomes in your app acceptance criteria.

Questions to settle before commissioning

Can the customer paste an existing brand code instead? Yes, request a manual field for your accepted format. Decide how staff handle a different colour reference rather than silently converting or relabelling it.

Does picking from a logo approve the colour? Not by itself. Ask who confirms the final specification and which original assets or approved references that decision uses.

Should every customer need this feature? No. If a named palette or supplied artwork already answers the need, screen sampling may add little. Discuss the actual request and approval journey when scoping your web app.

Source and limits

The Chrome Developers EyeDropper guide supports feature detection, user-triggered selection, sRGB hexadecimal output and cancellation. Field semantics, manual fallback, target protection and approval stages are proposed commissioning requirements, not claimed built or tested functionality.