Divi Fonts Not Loading: Google Fonts, Uploaded Fonts and Broken Icons

Generic headings, boxes for icons: what each looks like

A font failure leaves the site working and looking cheaper. Before changing settings, open the page in a private window, logged out, and note exactly what is wrong. Then open the browser's developer tools, choose the Network tab, filter by Font, and reload. A red line there tells you more than an hour of guessing.

• Headings or body text in a system font. A Google Font or an uploaded font never arrived, or was never requested.
• Icons shown as letters, numbers or empty squares. Divi's icon font failed, or loaded without the CSS that maps its characters.
• Symbols that flash for a second, then become icons. The icon font arrives late. That is a speed problem, not a missing file.
• Fonts right in the Visual Builder, wrong on the live page. Usually caching, or a plugin that only acts on logged-out visitors.
• One weight missing. Bold text drawn as a fake bold, because only the regular weight was loaded.

The cross-theme explanation of how fonts reach a page lives in WordPress theme fonts not loading. This page sticks to Divi's own settings, with each fix marked for Divi 4, Divi 5 or both.

Divi's three font pipelines

Each row breaks differently, which is why one fix rarely covers them all. Divi 5 also changed where fonts are managed: its changelog records the old global fonts editor being removed in favor of a fonts group in the Variable Manager, and Elegant Themes' design variables article says the Heading and Body fonts from the Theme Customizer appear there too.

Six causes, tested in order

1. Google Fonts were switched off on purpose (Divi 4 and 5)

Theme Options, General has a Use Google Fonts toggle. The Divi 5 help article puts it bluntly: disable it to remove Google Fonts from your Divi Builder pages. Someone may have done that for privacy reasons and forgotten. Check: open the toggle. Non-English text that shows the wrong characters points at Google Font Subsets, which enables Google Fonts for other languages.

2. A privacy or optimization plugin removed them (Divi 4 and 5)

Cookie and privacy tools often block requests to Google's font servers, and optimizer plugins can remove or localize them. Check: in the Network tab, look for requests to fonts.googleapis.com or fonts.gstatic.com. None at all means something removed them. Pick one tool to own fonts. If you want them off Google's servers, host them yourself rather than letting a plugin strip them silently. On Divi 4, developers can also use the et_builder_google_fonts_is_enabled filter added in 4.19.1.

3. Improve Google Fonts Loading is caching an old set (Divi 4; Divi 5 unverified)

This Performance option caches Google Fonts and prints them inline to cut render-blocking requests. Note the history: the Divi 4 changelog shows its default changed to off in 4.14.9, and earlier releases fixed bugs where the font cache was not used as intended. Check: if fonts changed in the builder but not live, switch the option off, clear caches, and test. We could not confirm the option's exact behavior on Divi 5.

4. The uploaded font is the wrong format (Divi 4 and 5)

Elegant Themes' help center lists .ttf and .otf as the formats Divi's font upload accepts, and says WOFF and WOFF2 files cannot be used in Divi even if you enable those uploads in WordPress. WordPress may also refuse the upload with "Sorry, you are not allowed to upload this file type". Fix: convert the font to TTF or OTF from a licensed source and upload again, choosing the supported weights when asked.

5. The uploaded file is missing or on http (Divi 4 and 5)

The vendor's custom-font article names two console errors. A 404 means the file is gone; re-upload it to the wp-content/et-fonts folder by FTP or the host's file manager. A mixed content error means the font is requested over http on an https site, a common leftover from a move. Our mixed content fix covers that cleanly.

6. A cache is holding old CSS (Divi 4 and 5)

Font declarations travel inside Divi's compiled CSS. If that file or a cached page is stale, the new font never gets requested. Clear Divi's CSS and every cache layer as described in Divi CSS not updating, then test again.

Icons that turned into alphabet soup

Divi's icons are characters in an icon font. When the font file fails, the browser draws the raw character with an ordinary font, which is why an arrow becomes a stray letter. Elegant Themes' broken-icons article lists four causes, and Dynamic Icons, on by default, is behind one of them.

• Icons used outside modules. Dynamic Icons loads icon subsets only when modules on the page need them. If custom CSS references Divi icons, Dynamic Icons may not load them. The vendor's fix is to turn Dynamic Icons off under Theme Options, Performance.
• http and https disagree. Check Settings, General: WordPress Address and Site Address must both match how the site is served. Back up first, as the vendor advises.
• CORS after a domain move. If the font is fetched from another hostname, the server must allow it, or the browser refuses the file.
• Plugin CSS overriding icon classes. Test with plugins off, or in Divi's Safe Mode, then re-enable one at a time.

Icons that show up late rather than never are a loading-order issue. Elegant Themes publishes a preload line for its icon font, modules.ttf, which sits in the theme's core/admin/fonts/modules/all folder; it goes in Theme Options, Integration, in the head field. On Divi 5, the 5.13 release added APIs so plugins and child themes can register their own icon fonts in the icon picker, which means custom icon sets from a child theme now have a supported route.

Bring the fonts back without breaking anything else

1. 1

   Read the Network tab

   Filter by Font in a private window. Note every failed request and its status: 404, blocked or mixed content.

2. 2

   Check Use Google Fonts

   Theme Options, General. Turn it on if your design relies on Google Fonts, and set Google Font Subsets if you publish in another language.

3. 3

   Find the plugin that owns fonts

   List every privacy, cookie and optimizer plugin with a font setting. Leave one in charge and turn font handling off in the rest.

4. 4

   Re-upload custom fonts as TTF or OTF

   Use licensed files, select the weights you need, and confirm the file returns a 200 status afterward.

5. 5

   Fix the address

   Make WordPress Address and Site Address match the https site, and update old http links after a move.

6. 6

   Test Dynamic Icons

   If icons used in custom CSS are broken, switch Dynamic Icons off and retest. Keep it on if nothing changes, because it saves weight.

7. 7

   Clear Divi's CSS and every cache

   Divi 4: Clear beside Static CSS File Generation. Divi 5: Clear CSS Cache in Theme Options. Then the caching plugin, host and CDN.

Divi 5 font fixes worth updating for

If you are on Divi 5 and fonts misbehave, check your version before anything else. The changelog shows a run of font fixes since launch, and a fault you are chasing may already be gone in a later release.

• Theme Customizer fonts not loading when using Source Sans Pro or other renamed Google Fonts, fixed during the public beta.
• Web-safe fonts such as Arial and Georgia in Global Font Variables sending invalid Google Fonts requests that returned 400 errors, fixed in 5.0.2.
• Duplicate Open Sans loading, fixed in 5.5.2.
• Global Heading and Body fonts not loading on Post Filter pages, fixed in 5.12.
• Google variable fonts such as Playfair Display showing a fake italic, fixed in 5.13.1.

To keep fonts stable afterward, set them once as site-wide variables rather than module by module, load only the weights the design uses, and recheck the Network tab after every update. Fewer fonts also help speed, which the Divi speed guide explains. Migrating from Divi 4? See Divi layout broken after an update for what else to test.

Why four tools fight over one typeface

On a typical Divi site, Divi requests Google Fonts, a performance option caches them, a cookie plugin blocks them, an optimizer tries to localize them and a CDN serves whatever copy it saw first. Each tool is doing its job. Nobody decided which one owns the fonts, so an update to any of them can bring the problem back. Our hosting and maintenance plans write that decision down and test it after every update, and the theme troubleshooting service handles one-off repairs.

A Next.js build handles fonts in one place. Its next/font module downloads the files at build time and serves them from the site's own domain, so there is no request to Google to block and no CDN header to forget. It costs more up front and needs a developer for layout changes. Compare the two in Divi vs Next.js, see the move in Divi to Next.js, and find other Divi faults in the Divi repair hub or the troubleshooting section. Owners of a rebuilt site edit in Athena CMS, where Picasso keeps images described and sized.