In Salesforce Experience Cloud (formerly Community Cloud), it is possible to add a custom font to an Experience Site to control site branding. However, there is a known limitation when an Experience Site has multiple domains — for example, both a custom domain and the native Force.com subdomain with a path prefix.
In this scenario, the custom font may be applied correctly on the live site but not reflected when viewing the site in Experience Builder, or vice versa.
Why this happens:
The @font-face CSS declaration used to apply custom fonts requires specifying a relative URL to the font resource. If the native Force.com subdomain has a path prefix (e.g., /Prefix), that prefix must be included in the font-face URL. Most custom domains do not have a path prefix. This creates a mismatch: the font works on the domain whose URL pattern matches the font-face declaration, but not the other.
For example:
@font-face {
font-family: 'exampleFont';
src: url('/s/sfsites/c/resource/MyFonts/bold/exampleFont.woff') format('woff');
}
This is a known limitation of Salesforce Experience Cloud when a site has both a custom domain and a native Force.com subdomain with a path prefix.
Recommended approach: Write the @font-face URL so that the custom font is applied correctly on the live site (using the custom domain, no path prefix):src: url('/s/sfsites/c/resource/MyFonts/bold/exampleFont.woff') format('woff');
This means the font will not render in Experience Builder (which uses the path prefix URL), but it will display correctly for end users on the live site. The live site experience takes priority for most organizations.
Always test custom font changes in a sandbox environment before applying them to a Production org.
000389103

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.