Font Pro - web fonts not displayed in all browsers? - solved

I just started playing around with Joe Workman’s foundation framework.
I linked a few purchased web fonts for testing and ran into a display problem.
My playground at will display as expected in RW’s preview mode, on Safari Browsers on different OS X devices and on an iPad running iOS 10.2. The fonts are being replaced by the fallback fonts in Chrome and Firefox on the OS X devices, both the latest versions. On the iPad, Firefox presents the fonts correctly. Didn’t try Windows or Android yet, for the lack of any such devices.

I also tried unchecking Consolidate CSS Files from the Advanced Options (General Settings) (Web fonts not displayed in MS Edge etc), but this didn’t solve the problem. No content blockers running on any of the above test devices.

1 Like

Your fonts are being blocked by Chrome and Firefox due to a CORS( Cross Origin Resource sharing). This stops content from other domains or even subdomains from being imported into your site.

The reason that it is happening is because you site (requesting the content) has an address beginning but the fonts are being referenced from the resources folder with url beginning with

The www address is considered as a subdomain and so the two locations are not the same as far as the CORS rules are concerned.

Two solutions are to either upload the fonts manually using an ftp app to a folder within your main site so that the font files are on the same subdomain (i.e. don’t use RW resources)
to add an htaccess snippet to tell these browsers to allow cross origin sharing - instructions for this are here under the Enabling CORS Access via a .htaccess file heading


wow, fastest support ever! Actually that was the problem. Placing the resources within the main domains root directory solved the displaying issues. Thank you!

I’ve been having this problem as well. Can you please explain further about adding fonts to my site? Where would I put them so they are on the same domain? Also, if I do that, do I have to move the resources, or can they stay in addition? or do you recommend the .htaccess file?
thank you!

It really just comes down to personal preference and workflow how you do it.

First up, look in the browser inspector at the CORS errors listed in the console. It will tell you the site address that is trying to load the font and the url to the font file. These must be on the same sub domain (remember .www is a subdomain). In the case above, the site was using http://www but the resources links generated just http://

The problem people find when using resources happens if page links are not set to relative. When relative the link to the font file will just start with / and so will always reference a directory within the site

Personally I would never load up a RW project file with fonts. I prefer to manage fonts separately and manually ftp them to the server. You have two choices here -

either create a folder within your site root (public_html or whatever it is on your host) and put the fonts in there. You can then just enter this url in FontPro and you will never have any CORS issues.

The other way to do it (and my preferred option) is to use a subdomain to store the fonts such as
This has the advantage that your fonts are totally separate from your site (should you wish to delete everything and republish then there is no danger of deleting the fonts by mistake) and also, multiple sites or subdomains of your site can all use the same font files.

In this case you just put the htaccess snippet from the link I posted above in the root directory of the subdomain on your server. If you want to specify just your domain, rather than the wildcard * then, in your case you would ensure that no one else can use your fonts in there site.

I hope that makes sense and just remember that the browser inspector in Chrome or Firefox is your best friend here as that will tell you if the domains of the font and the requester are different, and what the urls are.


I’m not a programmer so I’m sorry but am still confused. You’ve given me 3 options but I’m still not sure how to do it and which files to do it with.

Did you mean developer inspector, not borrower? I’m not sure how to read or search for the CORS. I went to my home page: and viewed the console and saw some Font Awesome 404s but not sure that’s what I’m looking for? The font that I use on my website and gets replaced is futura. Does that come from Font Awesome? Do I move the font awesome files to the root?

I searched for FontPro… is this what you mean?

I also have a .htcaccess file already at the root of the server. Do I add your snippet to that file?

thanks, Lisa

Yes - sorry auto correct at work again. I’ve now edited it back to browser.

All your errors appear to be simple 404’s (file not found) and have nothing to do with cross origin issues with webfonts

The font awesome errors look to be from RCP, the rest are all retina versions of your images which appear to not be found.

I searched for FontPro… is this what you mean?

yes the OP was using FontPro to load web fonts but the descriptions I gave above apply to all cases where self hosted web fonts are being loaded from a url, whether by Font Pro or not.

1 Like

So I don’t have the web font issue then? Must be my desktop computer then, as it looks fine on my laptop computer and my iPad and iPhone. I do have 2 versions of Futura… when I turn them both off things look ok.

Retina versions… is that just using larger images?

That RCP thing happens sometimes, sometimes it’s fine. I can’t get in touch with @rob for help, but that’s not your problem :slight_smile:

thank you :slight_smile:

@LSPhoto I may be reading you wrong but are you trying to use the fonts (Futura in your example) that are installed on your Mac in FontPro?
If so, this will fail. FontPro requires you to use webfonts NOT desktop fonts, they are as different as say a MSWord document and an Apple Pages one, both appear the same but are completely different under the skin.
What you need are .woff files not .otf or .ttf (though ttf may work)

If you absolutely must have Futura then you can get the individual styles from here but take a deep breath before you look at the price

If you want to have a play with a free webfont then I’d suggest you get FiraSans from here (click the green ‘Clone or download’ button). You’ll get all the file formats (otf, woff, ttf etc) but you only need to copy the .woff ones to a suitable folder on your server for FontPro.

This is a TotalCMS / FontPro driven database of all the fonts I’ve amassed, you’ll find FiraSans in the F’s


Not using FontPro. Only brought it up because it was mentioned. From what I can tell… it seems to be a conflict on my desktop computer that does not show the font correctly in Firefox and Chrome. It seems to be fine everywhere else, including my laptop.
I own Futura from ages ago as I am also a graphic designer, but not the webfont. Futura is built into my theme, as far as I know… you should see Futura when you view my website?

But thanks for the suggestions :slight_smile:

Andrew - does the .htaccess snippet to enable CORS work with a Cold Fusion server? I’m having difficulty loading fonts from the Cold Fusion server across domains. I’ve placed the .htaccess snippet in both the fonts folder and the root folder on the server. Thanks.

If the server is running Apache then it should work if placed in the root of the domain (or sub-domain) where the fonts are located. There are sometimes other restrictions enforced via the cPanel or directly by the hosts in which case you will need to speak to them.

Thanks for the quick response, Andrew. Do the fonts and the .htaccess file have to be in the root folder? and does the server have to be running Apache?

The htacess file has to be at the root of the domain (or sub-domain) in which the fonts are located. That is the only requirement. The fonts themselves do not have to be in the rood directory.

If your sever is not running Apache then you will need a different method. For example Nginx would require something like this:

location ~* "^.*?\.(eot)|(ttf)|(woff)$" {
  add_header Access-Control-Allow-Origin *;

but it would be best to check with the host provider.

1 Like

Very helpful, Andrew. Thanks very much.