The social icons in your footer have turned into little empty rectangles. The phone and envelope symbols next to your contact details are gone, or show as a question mark in a box. Headings that used to be in your brand font now look like plain Arial. Nothing else seems wrong, and the site still works, but it looks cheap all of a sudden.
Missing icons and fonts are almost never about the icons themselves. An icon set such as Font Awesome is a font file, and each icon is a character in that font. When the browser cannot fetch or use the file, it falls back to a default font that has no such character, and you get a box. So the question is always the same one: why did the browser fail to get the font file? Usually it is one of a handful of reasons, and most of them can be read straight off the browser’s console.
Read the browser’s own explanation first
Open the affected page, open your browser’s developer tools (F12 on most keyboards), and click the Console tab. Reload the page. Font problems almost always leave a red line here, and the wording tells you which cause you are dealing with. The common ones look like this:
- “has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.” The font lives on a different address from the page and the server did not give permission to use it. This is the most common case, and it gets its own section below.
- “Mixed Content: The page at ‘https://…’ was loaded over HTTPS, but requested an insecure font…” The font is being requested over plain http on an https page, and the browser refuses it.
- A 404 for a file ending in .woff2, .woff or .ttf. The file is not where the stylesheet says it is, often after a move, a theme update, or an optimisation plugin rewriting paths.
- “Failed to decode downloaded font” or an “OTS parsing error”. The browser got something, but not a valid font, often an error page or a file that was corrupted in transfer.
Firefox and Safari word these a little differently from Chrome, but the same ideas come through. The Network tab, filtered to “Font”, shows each font file the page asked for and the status code it got back. If a line says 200 and the icon is still a box, the problem is likely the class names rather than the file.
CORS: the font is on the “wrong” address
Browsers apply a rule to fonts that they do not apply to images: a font loaded from another origin is only allowed if that server sends an Access-Control-Allow-Origin header saying so. “Another origin” is stricter than people expect. These all count as different origins from each other:
https://example.comandhttps://www.example.comhttp://example.comandhttps://example.com- your site and a CDN address such as
cdn.example.com
So the typical stories are: the site was moved from www to non-www (or the reverse) and the theme’s stylesheet still points at the old form; a CDN was switched on and started serving fonts from its own hostname; or the site was copied from staging and some CSS files still refer to the staging address. If your site recently moved, our post on errors that show up after moving a site covers the other leftovers of an old address.
Fixing it
The cleanest fix is to make the font load from the same address as the page, by correcting the URL in the theme or plugin settings, regenerating the builder’s CSS, or fixing the old domain in the database. If the font has to come from a CDN, the CDN or the origin server needs to send the header. On an Apache or LiteSpeed server you can usually add it in .htaccess. Save a copy of the file first, because one typo in .htaccess can take the whole site down:
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|otf|eot|woff|woff2)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
On Nginx this goes into the server configuration instead, which on most shared plans is your host’s job. Most CDNs also have a setting for this, and after changing it you need to purge the CDN cache, or it will keep serving the old response without the header.
Other causes, in rough order of likelihood
An optimisation plugin changed how CSS loads
Caching and speed plugins can combine CSS files, move them, delay them, or strip out styles they think are unused. Each of those can break fonts. Combining files can break relative paths to the font files. “Remove unused CSS” features sometimes decide an @font-face rule is not needed. Delaying styles can leave icons blank until the visitor scrolls or clicks. The quick test: turn off CSS optimisation in that plugin, clear its cache, and reload in a private window. If the icons return, re-enable each feature separately until the icons vanish again, then add the font or icon stylesheet to that plugin’s exclusions.
Two versions of Font Awesome on one site
Font Awesome changed its class names between major versions. Version 4 used fa fa-phone; version 5 and later use prefixes such as fas, far and fab, and some icon names changed as well. If a theme was built with version 4 classes and a plugin update now loads only a newer version, some icons go blank while others still show. Page builders often have a compatibility setting for older icons; in Elementor it is a “Load Font Awesome 4 Support” option in its settings. Turning that on is a stopgap. The long-term fix is to update the old icon references.
Mixed content
If the console mentions mixed content, a font URL somewhere still starts with http://. That is usually hard-coded in a theme option, a custom CSS box, or old content in the database. Our guide to mixed content warnings on HTTPS sites explains how to find every insecure reference rather than only the first one.
Google Fonts switched off or hosted locally
Privacy and performance plugins often offer to stop loading Google Fonts, or to download them and serve them from your own server. Both are reasonable choices, but if the local copy failed to download, or the option was ticked without anyone checking, your headings drop back to a system font. Look in your theme settings, your builder’s settings and any privacy or speed plugin for a fonts option, and check the Network tab to see where the font files are now being requested from.
The server is not serving the files properly
Less common now, but older server setups sometimes do not know what a .woff2 file is, or hotlink protection in the hosting panel blocks requests for font files from a CDN. A security plugin or firewall rule can do the same. If the Network tab shows a 403 for the font, start with hotlink protection and firewall logs.
Dashboard icons missing too
If the icons in the WordPress admin menu are also boxes, the problem is wider than your theme. WordPress loads its own icon font, Dashicons, from its own files, so this usually points to a server rule, a security setting, or a plugin interfering with styles in the admin, rather than anything in the front-end design.
A sensible order to work in
- Note down which icons and fonts are missing, and on which pages. Is it everywhere, or only pages built with one tool?
- Open the console and the Network tab, reload, and copy the exact error text.
- Test in a private window and on a phone using mobile data, to rule out one browser’s cache or an extension.
- Clear the caching plugin, host cache and CDN cache, then reload.
- Switch off CSS optimisation temporarily to see whether it is the cause.
- Check whether the font URL uses the same address as the page: www or not, https or not, CDN or not.
- If you use a page builder, regenerate its CSS files, then clear caches again.
- Only then edit
.htaccessor CDN headers, with a copy of the original saved somewhere safe.
If what you are seeing is more than icons, whole sections unstyled or columns stacked on top of each other, you are probably looking at a stylesheet failing to load rather than just a font, and the steps in our layout repair service fit better. When only edits are missing rather than fonts, the cache guide on changes not showing up is the one to read.
Preventing it next time
- Pick one form of your address, www or not, and redirect the other to it. Make sure WordPress’s own settings use the same form.
- When you switch on a CDN or a new optimisation feature, check a page with icons in a private window the same day.
- Avoid loading the same icon set twice from two plugins. Builders, theme frameworks and “social icons” plugins often each bring their own copy.
- Keep custom fonts in the theme or a fonts plugin, not pasted into a custom CSS box with absolute URLs that break on the next move.
The wider family of display problems, along with errors that stop a site entirely, is mapped out on our WordPress errors and fixes page.
When it is worth asking for help
If the console shows a CORS error and you do not have access to the server or CDN settings, or the icons are tied up with an old theme that loads three different icon libraries, this can turn into a long afternoon. The same goes for a site where fixing one font breaks another.
If you message us the link and a console screenshot, by WhatsApp or the contact form, we save a copy of the site first, explain honestly which cause it is, and if it turns out to be part of a broader styling problem, our layout fix work covers that too.
Next in this series: WordPress Errors After Migration: What Broke and Why
