gradio ColorPicker — the colour swatch that quietly hands you a string

$ import gradio as gr

def swatch(hex_color: str) -> str:
    return (f"<div style='padding:14px 18px;border-radius:10px;"
            f"background:{hex_color};color:#fff;font:600 15px sans-serif'>"
            f"Run inference</div>")

with gr.Blocks(title="Brand picker") as demo:
    gr.Markdown("### Pick the primary colour for your demo")
    brand = gr.ColorPicker(value="#009245", label="primary", info="hex, #RRGGBB")
    go = gr.Button("Apply")
    out = gr.HTML()
    go.click(swatch, brand, out)

demo.launch()

Running on local URL:  http://127.0.0.1:7941

Rendered component tree: Markdown "### Pick the primary colour for your demo" -> ColorPicker (label "primary", info "hex, #RRGGBB", swatch showing green) -> Button "Apply" -> HTML output.

What the browser is told for that picker (read live from /config):
  {"value": "#009245", "label": "primary", "info": "hex, #RRGGBB", "show_label": true, "container": true}

The default swatch is a <button class="dialog-button" aria-label="primary" style="background: rgb(0, 146, 69);">. Click it and a .color-picker panel opens containing a .color-gradient (role="slider", aria-label="Saturation and brightness"), a .hue-slider (role="slider", aria-label="Hue", aria-valuemin=0, aria-valuemax=360), a preview .swatch, an eyedropper button, and a Hex / RGB / HSL mode row. In Hex mode the panel holds exactly one <input type="text">.

The handler is trivial because the component does the work -- swatch('#009245') returns:
  <div style='padding:14px 18px;border-radius:10px;background:#009245;color:#fff;font:600 15px sans-serif'>Run inference</div>
and swatch('#ff8800') returns the same markup with background:#ff8800. No conversion, no object, no .name attribute -- just the hex string you asked for.

All three examples were executed on gradio 6.18.0 / Python 3.13 by launching each app on its own port (7941-7943) and reading the served /config; the DOM lines come from driving the real widget in Chromium via Playwright. The launch banner port is whatever you pass to launch().

$ import gradio as gr

log = []

def note(name):
    def fn(v):
        log.append(f"{name}:{v}")
        return "\n".join(log)
    return fn

with gr.Blocks(title="Event order") as demo:
    c = gr.ColorPicker(value="#009245", label="accent")
    out = gr.Textbox(label="event log", lines=6)
    c.focus(note("focus"), c, out)
    c.blur(note("blur"), c, out)
    c.submit(note("submit"), c, out)
    c.change(note("change"), c, out)
    c.release(note("release"), c, out)

demo.launch()

Running on local URL:  http://127.0.0.1:7942

ColorPicker exposes exactly six listeners -- change, input, release, submit, focus, blur -- all wired above. Then I drove the real widget in a Playwright-controlled Chromium: click the swatch, type #ff8800 into the Hex field, press Enter. This is the server-side log, verbatim and in order:

  focus args=('#009245',)
  blur args=('#009245',)
  submit args=('#009245',)
  change args=('#ff8800',)

Read that twice. The colour you typed is only in the LAST line. focus, blur and submit all still carry the OLD value '#009245' -- submit fires a full round trip before change does, so a preview wired to .submit() is one interaction stale every single time. And when the handler that consumed .change() ran, it received '#ff8800':

  change received ('#ff8800',)

The swatch confirmed it too -- after the commit its inline style read background: rgb(255, 136, 0).

Event names and order captured from Python handlers instrumented with a shared log file, driven in a real browser. The old-value-on-submit behaviour is consistent with the 6.6.0 changelog entry 'Fix ColorPicker not firing focus, blur, or submit events after Svelte 5 migration' -- those three events have their own dispatch path.

$ import gradio as gr

def risk(score: float) -> str:
    return "#009245" if score > 0.8 else "#ff8800" if score > 0.5 else "#ff0000"

with gr.Blocks(title="Risk board") as demo:
    s = gr.Slider(0, 1, value=0.62, label="model confidence")
    sw = gr.ColorPicker(label="risk level", interactive=False)
    txt = gr.Textbox(label="shipped value")
    s.change(risk, s, sw)
    sw.change(lambda c: f"swatch now {c}", sw, txt)

demo.launch()

Running on local URL:  http://127.0.0.1:7943

Rendered component tree: Slider "model confidence" (0 to 1, sitting at 0.62) -> ColorPicker "risk level" (swatch with no initial colour, read-only) -> Textbox "shipped value".

What the browser is told (from /config):
  {"label": "risk level", "show_label": true, "container": true, "interactive": false}

interactive=False is what makes it display-only: the swatch renders and can be repainted by your function, but clicking it opens no picker. Feed it a computed colour and postprocess passes the string straight through:
  risk(0.62) -> '#ff8800'   risk(0.95) -> '#009245'   risk(0.10) -> '#ff0000'

And here is the part that surprises people -- the output side validates nothing either. postprocess() on 6.18.0 is literally `return str(value)`, so all of these are accepted and shipped to the client as the swatch colour:
  '#009245' -> '#009245'      'tomato'   -> 'tomato'
  'rgb(1,2,3)' -> 'rgb(1,2,3)' 'not-a-color' -> 'not-a-color'
  '#fff' -> '#fff'            '' -> ''            None -> None
preprocess() is `str(payload)` in the same spirit: gr.ColorPicker().preprocess('not-a-color') happily returns 'not-a-color'. 'tomato' is a valid CSS colour so the swatch goes red; 'not-a-color' is not, so the element falls back to whatever CSS decides -- silently, with no error in the Python log.

Both preprocess and postprocess read straight from the installed 6.18.0 source; every value in the table was executed, not reasoned about. If you want a validated colour, do it in your own function -- Gradio will not.