Cookies on this site

We would like to use cookies to understand how the site is used and to measure our campaigns. Nothing is set until you choose, and you can change your mind at any time from “Cookie settings” at the foot of every page. Privacy policy

Contact UsContact Us

Resources / Blogs

Cloud & apps

Why React Apps Show a 404 on Refresh in Azure Static Web Apps (And How to Fix It)

Learn how to fix React app 404 errors on refresh in Azure Static Web Apps using navigationFallback and staticwebapp.config.json.

· · 2 min read

Single-page React applications hosted on Azure Static Web Apps commonly run into a confusing issue: navigation within the app works perfectly, but refreshing the page or visiting a route directly results in Azure’s generic 404 error page instead of the application. This is a well-known mismatch between client-side routing and static website hosting, and it has a simple, one-file fix.

The cause

A React single-page application (SPA) is built around one physical HTML file: index.html. Routes such as /dashboard or /conversations are not real files on the server. They are virtual paths created and managed entirely in the browser by a React Router configuration, which swaps rendered content after index.html has already loaded.

This works seamlessly during in-app navigation since clicking a link never triggers a new request to the server. Instead, the browser re-renders content using JavaScript already running on the page.

A full-page refresh or direct URL access is different. It sends a brand-new request straight to the server for that exact path. Azure Static Web Apps checks for a matching file, finds nothing at /dashboard (since only index.html exists), and returns a 404 error.

This issue is one of the most common React SPA routing problems developers encounter when deploying applications to Azure.

The fix

Azure Static Web Apps supports a configuration option called navigationFallback, which instructs the server to serve index.html for any route that doesn’t match a real file. This allows the React Router and client-side routing logic to take over and render the correct page.

Create a file named staticwebapp.config.json inside the app’s public directory with the following content:

{
“navigationFallback”: {
“rewrite”: “/index.html”,
“exclude”: [“/static/*”, “/*.png”, “/*.jpg”, “/*.ico”, “/*.json”]
}
}

The exclude array ensures that requests for actual static assets—such as images, icons, and JSON files—are still served normally rather than being redirected to index.html.

Once this file is deployed, any unmatched route is treated as a valid React Router route rather than a missing file. As a result, the application loads correctly on page refresh and direct navigation.

This Azure Static Web Apps routing configuration is the recommended approach for preventing React app 404 errors on refresh.

Why isn’t this a bug

This behavior is not a defect in React, React Router, or Azure. It reflects a fundamental difference between client-side routing and server-side file resolution.

Any static hosting platform—including Azure Static Web Apps, Netlify, GitHub Pages, or AWS S3 with CloudFront—requires a similar route rewriting or fallback configuration. Applications that work during navigation but fail on refresh are almost always missing this setup.

For developers deploying a React app on Azure, configuring navigationFallback is a standard best practice that ensures consistent routing behavior across all URLs.

Summary

  • Symptom: 404 error on page refresh or direct URL access in a deployed React application.
  • Cause: Client-side routes do not correspond to real server-side files.
  • Fix: Add a navigationFallback rule using staticwebapp.config.json to redirect unmatched routes to index.html.
  • Scope: Applies to Azure Static Web Apps and other static hosting platforms running a single-page application (SPA).
  • Benefit: Eliminates React Router 404 refresh issues and ensures reliable Azure Static Web Apps routing for direct URL access.

← All articles

Case studies

Cloud Consulting in practice

Client names are withheld. We are happy to share details on a call.

All case studies
  • Delivered

    On-prem → Amazon RDS

    Nonprofit

    Cloud Consulting

    Oracle from on-premises to Amazon RDS for a national nonprofit

    The nonprofit's on-premises Oracle database had become hard to maintain and scale. We planned the move with automated workflows and validation tests, migrated to Amazon RDS for Oracle with minimal disruption and left a repeatable process for future changes.

    • Automated, tested migration
    • Less day-to-day database upkeep
  • Delivered

    600k files, < 3 days

    Document management

    Microsoft

    600,000 documents moved from ImageRight to SharePoint in under three days

    A one-file-at-a-time script would have needed about 22 days of continuous running. We rebuilt the migration around a SQL work queue with parallel uploads, automatic retries and crash recovery, and it finished unattended in under three days.

    • 1,125 → 8,314 files per hour
    • Under 3 days instead of about 22
  • Delivered

    Every change, flagged

    Food manufacturing

    AI Consulting

    Label comparison agent for a national food cooperative

    Compares two versions of a product label, highlights every change, annotates the PDF and returns an audit-ready list of differences. We moved it from Copilot Studio to Azure Functions when the document processing outgrew the low-code platform.

    • Audit-ready differences in one chat turn
    • Rebuilt from low-code to cloud functions

Keep reading

All Cloud & apps articles

Moving an application to the cloud?

Request a migration plan consult. We will scope the move with you and come back with a fixed-scope plan.