Platform
Choosing a readable brand palette from a logo
Extracting colours from a logo gives you a starting point, not a palette. What to do with the result so the interface built from it is still readable.
8 min read · Reviewed 2026-09-21
In short
Let the customer choose an accent, derive the rest, and check contrast before you save rather than after. Never let a brand colour become body text or a large background without a contrast check, and always keep status meaning in words as well as colour.
A white-label portal is an easy feature to describe and a hard one to do responsibly. The moment you let somebody pick a colour, you have handed them the ability to make your product unreadable — and the person who suffers is not them, it is their customer.
Take one colour, derive the rest
Ask for an accent and nothing else. From it, derive the states you need — hover, pressed, a soft background tint — rather than asking for five colours that will not relate to each other. Fewer inputs means fewer ways to produce something unreadable, and it means the result looks designed rather than assembled.
If you extract a palette from an uploaded logo, treat the result as a suggestion the customer confirms, not a setting you apply. Extraction picks up antialiasing edges and background colours surprisingly often.
Check contrast at the point of saving
WCAG 2.2 sets out the contrast minimums: 4.5:1 for normal text, 3:1 for large text and for the visual boundaries of user-interface components. The check is arithmetic on two colours and takes microseconds, so do it while the customer is looking at the form and can change the colour, not in a support ticket three months later.
- If the accent fails against white, do not refuse the colour — use it where it works. A brand teal that fails as text can be fine as a 4px bar, a border or a fill behind dark text.
- Keep a separate, darker variant of the brand colour for text and links, derived automatically, and say that is what you have done.
- Never put body text on the accent without checking.
A brand colour is a graphic identity, not a text colour. A palette can contain a colour that is beautiful and unusable for reading: GENV's own accent, #00D4B2, measures 1.90:1 on white, against the 4.5:1 that WCAG AA asks of body text.
Status must survive colour
Paid, overdue, suspended, active: if these are distinguished only by colour, they are invisible to a portion of your customers and to anybody printing in greyscale. Every status needs a word. The colour is an accelerator for people who can see it, not the information itself.
The parts branding must not touch
| May change | May not change |
|---|---|
| Accent colour, logo, display name | Focus outlines — they are how keyboard users navigate |
| Header and footer content | Minimum touch target sizes |
| Whether a section appears | Error and warning text colours below the contrast threshold |
| The portal's name in copy | The meaning or wording of a status |
Test the portal the way customers use it
- At 360px wide, which is still a real phone size.
- With a keyboard only. Every control reachable, every focus ring visible against the brand colour.
- With reduced motion, which should turn off transitions rather than break layout.
- In greyscale, to catch colour-only meaning.
- With the longest realistic business name, which is where headers break.
Where GENV is
GENV's portal branding takes an accent and a display name, derives the rest, and the design system keeps two brand teals for exactly the reason above: the bright one is right on navy and in dark mode, and a deeper variant carries text and links where the bright one would fail. Statuses carry words rather than colour alone. The application is built and checked at 390px and 1440px in both light and dark themes.
Questions
Should customers be able to upload custom CSS?
Not unless you are prepared to support whatever they break, including accessibility regressions you become responsible for. A constrained set of choices is better for both sides.
What about dark mode in a branded portal?
Derive it rather than asking for a second palette. A brand colour that fails on white usually works on a dark surface, which is why deriving both from one input works well.
Is a custom domain necessary for white-labelling?
Not to begin with. It is the part with the most operational weight — certificates, renewals, DNS support — and it is reasonable to offer branding first and custom domains later.
Sources
Official documentation, each requested on 21 September 2026. Provider behaviour changes; check the source before relying on a detail.