Colours, fonts and logos
The detail behind the theme panel: what a colour value may look like, which fonts are available, and why a logo sometimes shows in one place and not the other. Read this when a theme value you set appears to have no effect.
Colour formats
Section titled “Colour formats”The three colour controls in the builder are native colour pickers, so anything you set there is a valid hex value. This list matters for the other way a colour reaches a form, an imported blueprint, whose theme can carry any of these as text:
| Form | Examples |
|---|---|
| Hex | #1B76D1, #fff, #ffffff80 (eight-digit hex carries transparency) |
| Colour name | white, rebeccapurple, transparent |
| Older functions | rgb(27, 118, 209), rgba(0, 0, 0, 0.5), hsl(210 100% 50%) |
| Modern functions | oklch(0.7 0.15 250), oklab(...), lab(...), lch(...), hwb(...), color(display-p3 1 0 0) |
color-mix() is not supported. Anything that is not one of the forms above is ignored rather than rendered, and the form falls back to the packaged default, so a colour that seems to do nothing is worth checking against this table first.
Corner Radius and Field Spacing take a non-negative CSS length: 1rem, 12px, 0.5em, or 0. A negative value, or anything that is not a length, is ignored the same way.
Font family is chosen from a short list in the builder: system, sans-serif, serif and monospace stacks that every browser already has, plus a Custom option for a stack you have made available yourself.
Nothing in the package fetches a web font, and Lightning blocks external font services, so naming a font that is not installed on the respondent’s device quietly falls back to the default. To use your own font, serve it from a static resource in your org.
A logo is set per form, in the builder’s theme panel, as an https:// address. Anything else, such as http://, a data address, or a relative path, is ignored rather than rendered.
An external logo host has to be registered before the image will appear, in up to two separate places, and this is the most common reason a logo shows up in one place and not the other:
| Where the form renders | Governed by |
|---|---|
| The builder preview, inside Salesforce | Setup, Security, CSP Trusted Sites, with the image context enabled |
| The public form on an Experience Cloud site | That site’s own security settings, configured separately |
Because those are independent, a logo can load on the live form and stay blank in the builder, or the reverse. This is a step you have to take: a package can only pre-authorise a fixed address, never one an admin types later.
The builder says so inline rather than leaving a blank space. A well-formed https logo that fails to load is replaced with a short note naming the possibilities: a wrong address, an unreachable host, or the security setting above. The builder cannot tell those apart, because they all surface the same way, so check the address first.
Hosting the image inside your own org avoids the question entirely. A static resource, or a file on the site itself, is also the more robust choice: an external host can move the asset, throttle it, or serve it slowly on every render.