Problem

When hosting an Angular application on Azure Static Web Apps, there is one small caching detail that can cause a surprisingly annoying issue:

index.html can be cached by the browser.

That might sound harmless at first, but for a single-page application it can prevent users from getting the latest version of the app after a deployment.

The fix is simple: tell Azure Static Web Apps to instruct the browser not to cache index.html.

Angular production builds usually generate files like this:

main.8f3a1c2d.js
polyfills.1d4a9b7e.js
styles.2c9f0a11.css

These files are fingerprinted with a hash in the file name. That is great for caching because when the content changes, the file name changes too.

So caching files like JavaScript, CSS, images, and fonts is normally fine.

The problem is index.html.

The index.html file is the entry point for the Angular app. It contains references to the generated JavaScript and CSS files.

For example:

<script src="main.8f3a1c2d.js" type="module"></script>

After a new deployment, Angular may generate a new file:

main.a91b72ff.js

But if the browser still uses an old cached version of index.html, it may keep trying to load the old JavaScript bundle.

Depending on your deployment setup, this can result in issues such as:

  • users not seeing the latest version of the app
  • old JavaScript bundles being loaded
  • ChunkLoadError errors
  • the app appearing broken until the user does a hard refresh

Not a great experience.

Solution

The solution is to configure Azure Static Web Apps to return cache headers for index.html that prevent the browser from caching it.

In Azure Static Web Apps, this is done using the staticwebapp.config.json file. Typically, you will put this file in the public folder of your Angular application.

Here is an example configuration:

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": [
      "/*.{css,scss,sass,js,mjs,map,ico,png,jpg,jpeg,gif,svg,webp,woff,woff2,ttf,eot,txt,xml}",
      "/assets/*"
    ]
  },
  "routes": [
    {
      "route": "/index.html",
      "headers": {
        "Cache-Control": "no-cache, no-store, must-revalidate"
      }
    }
  ]
}

The important part is this route:

{
  "route": "/index.html",
  "headers": {
    "Cache-Control": "no-cache, no-store, must-revalidate"
  }
}

This tells the browser that index.html should not be stored and reused without checking for a fresh version.

After deploying, you can verify the response headers using your browser dev tools or curl. You should see something like Cache-Control: no-cache, no-store, must-revalidate

edi@edi-pn61:~$ curl -I https://tools.edi.wang
HTTP/2 200
content-type: text/html
date: Tue, 05 May 2026 03:44:29 GMT
accept-ranges: bytes
cache-control: no-cache, no-store, must-revalidate
etag: "93063574"
last-modified: Mon, 04 May 2026 05:42:45 GMT
content-length: 3704
strict-transport-security: max-age=10886400; includeSubDomains; preload
referrer-policy: same-origin
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-dns-prefetch-control: off