Hex-Locked Color: Getting Exact Brand Values Out of Prompts
Typing a hex code into a prompt doesn't guarantee the model hits it. Which models actually treat hex as a spec, and how to verify the ones that do.
A brand team writes #FF5733 into a prompt and gets back a plausible orange. Close, warm, in the right family — and not actually the hex value they specified. That gap between "the model understood I wanted orange" and "the model hit the exact numeric target" is where brand consistency quietly dies across a content batch, one slightly-off render at a time.
Why hex gets approximated in the first place
Most text-to-image models learn color from natural-language captions during training — "crimson," "burnt orange," "sky blue" — associated probabilistically with regions of pixel space, not from hex codes treated as exact numeric targets. A hex string is a fairly out-of-distribution token for a model trained mostly on descriptive color language. Unless a model has been specifically built or prompted to treat a hex code as a precise instruction rather than a strong suggestion, it tends to land in the right neighborhood rather than on the exact value — which is often good enough for a single asset and never good enough across twenty assets that all need to match.
That last part is the actual stakes. A single off-brand orange in isolation reads as fine — nobody has a reference point to judge it against. The same color sitting in a grid next to nineteen other assets, some of which happened to land closer to the true value than others, reads as a batch that doesn't match itself, which is a worse failure than any individual asset being wrong. Hex precision matters least on a one-off image and most exactly where AI generation is used hardest: high-volume, repeated-asset production where consistency across the set is the entire point.
A model actually built to hit the value
FLUX.2 is a real exception here, with an important condition attached. Black Forest Labs' own prompting documentation states that FLUX.2 "supports precise color matching using hex codes" — signaled in a prompt with a keyword like "color" or "hex" directly followed by the code — and that hex references work best when they're clearly tied to a specific object in the prompt. The same documentation is explicit about the failure case: a vague, floating reference like "use #FF0000 somewhere" tends to produce inconsistent results. Precision isn't automatic across the whole image — it's earned by binding the hex code to something specific ("a burgundy #800020 leather strap," not just "#800020 in the scene somewhere").
That's a meaningfully more honest claim than "always exact," and it's the actionable version: hex accuracy with FLUX.2 is a prompting discipline as much as a model capability. Versely carries several FLUX.2 variants at different price points — Flux 2 Pro at 3 credits up to Flux 2 Max at 7 credits — so the hex-matching behavior is available across a range of quality and cost tiers on the full model catalog, not gated to the most expensive option.
The verification step, regardless of which model you used
Even a hex-aware model can drift, and a model that wasn't built for it will drift more. The fix that actually catches both cases is the same: check the rendered pixel value against the target, rather than trusting that a prompt containing the right code produced an image containing the right color. Any color-picker or eyedropper tool pulling the exact pixel value from the output and diffing it against the target hex is a two-minute check that catches what a glance won't — colors that are close enough to pass a casual look and off enough to read as wrong sitting next to the real brand asset.
There's a subtlety worth knowing about even when a value technically matches: hex and rgb() in CSS assume an implicit sRGB color space, whereas the color() function exists specifically to address a value in an explicitly named color space rather than assuming sRGB by default. The practitioner takeaway isn't that you need to reason about color spaces for every asset — it's that "the same hex string" isn't automatically apples-to-apples across every context it appears in. Comparing a generated image's color against a brand guideline in the same viewing and color context (not a hex value eyeballed in one app against a render viewed in another) removes a whole category of false "it's off" or false "it matches" judgment before it happens.
Making the palette persistent instead of re-typed every time
The other half of hex consistency has nothing to do with which model renders it best — it's whether the exact value gets re-typed correctly into every single prompt or gets remembered once and applied automatically. Versely's brand kit tooling is built for the second version. Setting a brand kit works conversationally — sharing something like "our color is #FF5733" in chat is enough to save it — and the underlying write is a partial upsert: only the fields you actually pass get changed, and for the colors and fonts objects specifically, it's a key-merge rather than a whole-object replace, so adding a second brand color later doesn't overwrite the first one you saved.
Once saved, the kit isn't something you have to remember to reference — it's auto-injected into context, so subsequent generations and workflows apply it by default without the hex code needing to be retyped into every individual prompt. That removes the most common source of drift in practice, which usually isn't the model mis-rendering a correctly-specified color — it's a hex code typed slightly wrong, or omitted entirely, on generation eleven of a batch where the first ten were careful about it.
What to do with a model that won't hit hex reliably
Not every job needs a hex-precise model, and forcing one onto every generation trades away speed or cost for a precision that doesn't always matter. A reasonable split: reserve a hex-aware model specifically for hero brand assets — anything sitting next to the real logo or published brand guideline, where a visibly-off color reads as a mistake — and use faster or cheaper models for compositions where exact color matters less than getting volume out quickly. For that second category, treat color correction as a deliberate separate pass rather than something the generation prompt is responsible for getting exactly right on its own; asking a general-purpose model to nail an exact numeric target it wasn't built to hit is asking it to do a job a color-grading pass does more reliably anyway.
This is also where testing pays off before a full batch runs, not after. Generating one asset with the target hex, checking the pixel value, and only then committing to the same model and prompt structure for the remaining nineteen is a few minutes of overhead against a batch that might otherwise need a second pass across every single asset once the drift is noticed at the end instead of the start.
The actual discipline
Hex-locked color isn't really about finding the one model that never drifts — it's a three-part habit: pick a model that treats hex as a target rather than a hint when precision actually matters, bind the hex code to something specific in the prompt rather than leaving it floating, and verify the pixel value on the output instead of trusting that a correct-looking prompt produced a correct render. Do the first part once by comparing image models directly against the full catalog for a given job, and let a saved brand kit handle the second and third from there on out — the model matters less than the discipline once the palette itself stops being something anyone has to remember to type.