Azure Fonts Not Showing | Fast Fixes For Web Apps

When you push a site to Azure and custom typefaces vanish, the page feels broken. Text falls back to generic faces and layouts shift.

This guide walks through the main reasons fonts fail on Azure and how to check paths, CORS, MIME types, and platform quirks.

What Causes Azure Fonts Not Showing?

Quick scan: when fonts do not appear in an Azure hosted site, the browser almost always reports one of four problems in the network or console panels. Each points toward a different layer in your setup.

• 404 not found errors — the CSS points at a path that does not exist once the app runs on Azure, so the font file never reaches the browser.
• CORS blocked errors — fonts sit behind a different origin such as Azure CDN or a storage account, and CORS headers do not allow your site to read them.
• MIME type or 500 level errors — App Service or the server behind it does not know how to serve .woff2, .woff, or other font types.
• Runtime or platform limits — private fonts loaded through .NET APIs or system level installation hit limits inside App Service or Functions.

Before you tweak Azure settings, open the browser developer tools on a page that should show the font. Under the Network tab, filter by font or by file extension. That view reveals which requests fail and which status codes or errors appear. Once you see the exact failure, you can match it against the right fix in the rest of this guide.

Symptom	Likely Cause	Where To Fix
Fallback font or empty squares	404 or wrong path in @font-face	CSS and build output
Font blocked by CORS policy	Missing or narrow CORS rules	App Service, Blob, or CDN CORS
Font request 404 or 500 for .woff2	MIME type not registered	web.config or site extension

Quick Checks Before You Change Azure Settings

Fast local checks: small mistakes in the project often look like Azure bugs. Running through a short checklist saves time before you dig into portal settings.

• Confirm the font files exist in output — after your build step, inspect the folder that you publish to Azure and confirm that the fonts directory and files actually ship with the app.
• Match paths in @font-face rules — compare the src URLs in CSS with the folder layout in the built site; relative paths often break when the app runs under a virtual directory or with a different base path.
• Check case sensitivity — Azure storage and some Linux plans treat file names with case differences as separate files, so MyFont.woff2 and myfont.woff2 are not the same.
• Test a hard refresh — clear cache or open a private window to rule out stale font caches, especially while you adjust CORS and headers.

Once those basics pass, you can narrow down the problem to a specific Azure service. The next sections walk through CORS, MIME types, and routing issues in more detail, since those drive most reports of azure fonts not showing in production.

Fix CORS When Azure Fonts Are Hosted On Another Origin

Why CORS matters: browsers treat fonts as special resources that must obey CORS rules whenever they cross origins. If your site lives at one host and fonts come from Azure CDN, Blob Storage, or another App Service, you need matching CORS headers on the origin that serves the fonts.

• Check the error message — in the console, look for text such as No 'Access-Control-Allow-Origin' header is present beside the font URL; that message confirms a CORS problem instead of a bad path.
• Set CORS in App Service — in the Azure portal, open the App Service that hosts the fonts, choose the CORS settings, and add the origin of your web site or * during testing so the font responses include the correct header.
• Configure CORS for Blob or CDN — when fonts live in a storage account behind Azure CDN, update the storage CORS rules so the allowed origins include your site and make sure those origins sit in a single rule when needed.
• Match protocol and host — the origin string must match the scheme and host visitors use, such as https://www.example.com, not the bare domain.

Azure App Service ships with built in CORS features, and you can also control headers through CDN rules or storage account settings. The aim is simple: every font response should echo the requesting origin in an Access-Control-Allow-Origin header with a status in the 2xx range, so the browser accepts and applies the font.

Fix Missing Font Mime Types In Azure App Service

Mime type check: even when paths and CORS look fine, an App Service site can still return 404 or odd 500 status codes for font files. This often happens because IIS inside App Service only serves a fixed list of static types, and popular font formats sit outside that list by default.

• Inspect the response headers — in the Network panel, select a failed font request and check the response; if you see a 404 from the server and no custom headers, missing MIME types may sit at the root of the problem.
• Add MIME types through web.config — in an ASP.NET or IIS backed app, extend the <staticContent> section with mappings for .woff2, .woff, and .ttf so the server treats them as static assets.
• Use a site extension when present — several extensions in the Azure marketplace add common static file types, including web fonts, without manual XML edits; once installed, they register the right mappings inside App Service.
• Restart the app after changes — once you add MIME entries or site extensions, restart the App Service so the new configuration loads before you test again.

If you run on a Linux App Service image or a container, the platform may use a different web server such as Nginx. In that case, add matching types entries or static file mappings in the server configuration inside your container image and redeploy, since the Azure portal web.config path only affects Windows based plans.

Fix Font Paths And Deployment Issues In Azure Static Web Apps

Path related quirks: Azure Static Web Apps adds its own routing layer in front of your files. When the base path or trailing slashes differ from local development, relative URLs in CSS may point at the wrong place, leaving Azure font requests failing while the assets already sit in the service.

• Inspect the final URLs in production — open the font request in the Network panel, copy its full path, and check whether that file exists in the deployed output_location of your static app build.
• Avoid parent directory climbs — paths with many ../ segments can break when the app sits behind a different base path; prefer root relative URLs such as /assets/fonts/MyFont.woff2 when possible.
• Watch for missing trailing slashes — Static Web Apps may serve a folder index without a slash, which can confuse relative paths inside linked CSS assets; confirm that links to style sheets and fonts use consistent paths.
• Check your build pipeline — some bundlers place fonts under hashed file names; ensure the CSS that runs on Azure points at those hashed names, not at the original source file names from your repository.

Once you align paths between your build output and the deployed site, the font requests should move from 404s to 200s. At that point CORS and MIME type tuning, if needed, handle the last mile between Azure and the browser.

Azure Font Issues With Azure Cdn Or Storage

Edge cases with shared origins: many teams place fonts in a shared Azure Blob Storage account or behind Azure CDN so several sites can reuse the same assets. This pattern reduces copies of the same files, but it adds another origin hop, which adds another place where CORS and headers can fail.

• Align CORS rules across origins — when multiple sites call the same CDN endpoint, set rules that list every domain in one entry where the service expects a single row of hosts instead of separate rows.
• Check CDN rules that rewrite headers — some CDN profiles use rules engine steps that overwrite response headers; review them to be sure Access-Control-Allow-Origin and Vary: Origin still match what you expect.
• Confirm HTTPS and host match — fonts called from https://www.example.com may still fail if CORS only lists http://example.com or another variant; tighten the set of origins to match live traffic.
• Test direct origin access — request the font straight from the storage endpoint without CDN; if that works, the issue likely sits in CDN rules or caching instead of the storage account.

Once CDN and storage settings line up, fonts should load from edge nodes with the same headers you would expect from the origin. That keeps latency low while still passing CORS checks in modern browsers.

When Azure Fonts Still Refuse To Show

Last checks: if paths, CORS, and MIME types all look correct and azure fonts not showing persists, a few platform specific details may still block the result you expect.

• Private fonts in .NET code — some server side report engines and libraries try to load fonts from disk through APIs that call GDI, which App Service may block; in that case, moving to a different hosting plan or container with system level font installation can help.
• OS level font installation — when you need fonts installed on the underlying host instead of served as static files, a Web App for Containers plan or a full VM gives control over the OS so you can add fonts during image build.
• Mixed content and security headers — fonts loaded over HTTP on an HTTPS site, or fonts blocked by a strict Content Security Policy, will never render; align all font URLs with HTTPS and update CSP directives.
• Third party script interference — some optimization tools rewrite asset URLs; if a script rewrites font paths without awareness of Azure routing, disable that feature and retest.

At this stage you have a clear map of the usual causes and fixes for font trouble on Azure: file paths and build output, CORS rules on App Service, Blob Storage, and CDN, MIME type registration, and a short list of platform quirks. With those pieces in place, your custom typefaces should now render the same on Azure as they do in local development, and the next time fonts disappear you will know exactly where to look.