A brand's color palette is one of the most reliable carriers of visual identity. When someone encounters your brand across a campaign — story ad, display unit, email header, social post — the consistent recurrence of specific color values is part of what registers as recognition. The hex value matters. Not approximately; exactly.
And yet palette drift — the gradual accumulation of small color deviations across a campaign's production assets — is endemic to in-house brand teams. It's not caused by designers who don't care about accuracy. It's caused by a structural problem in how color makes its way from a brand specification into a generated export, and the problem lives at the production layer, not in the brand guide.
Where the drift actually comes from
Most color drift in produced assets doesn't come from designers misremembering hex values. It comes from the gap between how color is specified and how it travels through a production workflow.
The most common drift source is the eyedropper. When a designer needs to match a background color on a resized asset to the original master, the instinct is to use the eyedropper tool to sample from the master. This seems accurate but introduces a subtle error: JPEG and WebP compression alter pixel-level color values from their source. Sampling a JPEG export of your brand's primary color with an eyedropper often returns a value 3–8 Delta E units from the original, which is invisible in isolation but accumulates into a visible difference when compared to other assets produced from the original spec.
The second drift source is library staleness. Teams that maintain a shared color library — whether in Figma tokens, a DAM system, or a shared Swatch panel — often have the library's current version diverge from assets being produced from older Figma files that were cloned from an even older master template. When the brand updates a color value by even a few digits, that update propagates to new work but not to the existing campaign files that designers are working from.
The third drift source is contractor workflows. External contributors — freelance designers, agency partners handling a sub-set of deliverables — typically receive a brief and an asset pack rather than direct access to brand token files. They reproduce colors by visual matching, by copying hex values from a PDF brand guide, or by sampling from provided assets that may themselves already carry drift from the sources above.
Why the brand guide doesn't solve it
The brand guide documents the correct values. That's its function, and it does that function correctly. The problem is that documentation is not enforcement. A designer who knows the correct hex value and uses it when working in the source design file may produce an export that drifts from it anyway, because the drift happens downstream of the design decision.
Color profile mismatches are a significant contributor here. A designer works in an sRGB color space and exports to a JPEG or WebP. The asset is then used as a source for another export, sometimes opened in software that applies a different color profile by default. The resulting background fills, even when sampled "accurately," are operating in a context where the color pipeline itself introduces variation. This is particularly pronounced in dark backgrounds — deep navies, near-blacks, very dark brand colors — where small Delta E differences are more perceptually significant than they are in mid-tone or pastel ranges.
Background generation is the failure point most often overlooked in brand QA. Designers review foreground elements — logo position, typography, image composition — with high attention. Background fills are reviewed as "looks right," which is not the same as "is correct." Palette drift accumulates primarily in generated backgrounds.
A production scenario
An in-house brand team at a growing consumer brand in 2025 ran a seasonal campaign that included assets produced by two staff designers and one freelance contractor. The brand's primary background color is a deep navy: #12213A. The staff designers worked from a shared Figma library with the token correctly set. The contractor received an asset pack including a reference JPEG of the hero creative.
When the campaign's display assets were assembled for a pre-flight review, the contractor's five deliverables had backgrounds ranging from #11203B to #142540 — a range of roughly 10 Delta E units around the target. On individual screens in isolation, none of these looked wrong. In a side-by-side review of the full campaign asset set, the variation was visible, particularly at the darker end of the deviation where #142540 read with a slightly warm undertone against #12213A's cooler cast.
The fix required reopening five files, correcting the background fill using the exact hex value, and re-exporting. That's a revision cycle that existed entirely because color didn't travel with the work — it was manually reproduced at each production step.
What palette locking actually means in practice
Palette locking, as a production mechanism, means that generated backgrounds and color fills in exported assets derive from encoded hex values rather than from sampling, approximation, or manual entry. The system applies the color; the producer doesn't intervene in that step.
This requires that the production pipeline have the brand's palette encoded as a locked token set, not just as a reference document. When generating a background fill for a resized asset, the system uses the token value directly, regardless of what the input asset's pixel values happen to be after compression. The output color is the brand color. Not close to it.
The contrast with guideline-based workflows is worth stating clearly: in a guideline-based workflow, color accuracy depends on every contributor at every production step correctly applying the specification. In a token-enforcement workflow, color accuracy depends on the token set being correctly maintained once — and then it propagates correctly to every subsequent export automatically.
The token maintenance problem
We're not claiming that palette locking eliminates all palette-related problems. It shifts the problem from distributed enforcement to centralized maintenance, which is a better problem to have — but it is still a problem.
If the token set is outdated — if a brand refresh updated a secondary color and the token file wasn't updated — then the automation enforces the wrong value with the same confidence it enforces a correct one. This is arguably worse than human error, because human error tends to produce visible drift that signals something is wrong, while consistent enforcement of an outdated value produces assets that look internally consistent but are incorrect.
The implication is that palette locking requires pairing with a clear token ownership and update protocol. Someone is responsible for maintaining the canonical token file; that person is the single point of update when brand values change; and production workflows derive from that file and only that file. This is not a technical challenge — it's a process discipline challenge. The technology can enforce consistency; only people can ensure the values being enforced are the right ones.
Drift as a quality signal
One underappreciated aspect of systematic palette enforcement is what it reveals about your brand's production health. Teams that haven't implemented palette locking often don't know how much drift exists in their active asset libraries, because they've never had a mechanism to measure it. When a new campaign's assets are generated from locked tokens and compared to existing assets in the DAM, the extent of legacy drift becomes visible for the first time.
This visibility is useful, even when the news is uncomfortable. A brand library with significant palette drift across its historical assets is a liability — not an urgent one, but one that compounds over time as those assets continue to be used as reference points in new production work. Knowing the extent of the problem is the prerequisite to addressing it, and palette enforcement tooling tends to surface that extent as a byproduct of doing the production work correctly going forward.
