Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsA JavaScript site that works locally but fails after deployment is usually encountering a difference in the production build, hosting path, server routing, filesystem, or environment configuration—not one universal bug. First identify what fails and when: the build, initial page load, a JavaScript or CSS asset, a direct route or refresh, an API request, or a lazy-loaded module. Then use the matching checks below rather than changing unrelated settings.
Start by reproducing the problem with the production build
A development server and a deployed site do not necessarily use the same build output, asset URLs, environment values, or routing behavior. Build and serve the production output before editing configuration. Vite, for example, creates production output with vite build; its documentation says that command is used when it is time to deploy an app for production: Vite: Building for Production. Use the preview or production-serving method documented for your framework, and test the same URL or route that fails on the live site. Do not open a generated HTML file directly with a file:// URL: Vite notes that browser cross-origin rules can block module loading that way, and recommends serving the files over HTTP, such as with Vite Preview: Vite: Troubleshooting.
As an Amazon Associate I earn from qualifying purchases.
Collect evidence before making a change
- Open the browser developer tools. In Console, note the first relevant error; in Network, check the document, JavaScript and CSS files, and API requests. Record the failing request’s URL and status.
- Check the deployment platform’s build output and, where available, request or server logs. A build failure, a missing static asset, and a rejected API request require different fixes.
- Compare the failing production URL with the local one. Note whether the site is at the domain root or under a subdirectory, whether only direct navigation or refresh fails, and whether the problem began after a release.
If JavaScript or CSS files return 404
Look at the failed asset URL in Network. If the app is hosted below the domain root—for example, under a project path—the build may be requesting assets from the wrong public path. Configure the base path according to the framework and the actual deployment URL. Vite’s base option rewrites asset references in JavaScript imports, CSS url() references, and HTML; dynamically constructed URLs can use import.meta.env.BASE_URL. See Vite’s production build guide. Vite’s exact behavior does not imply that another framework uses the same setting.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallAlso verify that the host publishes the directory produced by the production build—not the project source directory or a different output folder. The required directory and configuration depend on the framework and hosting platform; use that platform’s deployment instructions. A base-path correction cannot fix a host that is serving the wrong files.
#1 Best Overall
If a route works in the app but fails on refresh
Client-side navigation can make a route such as /about appear to work: the browser has already loaded the app, which then changes the displayed page. On refresh or direct entry, however, the browser asks the server for /about. If the deployment treats that request as a request for a physical file and has no matching file, it can return 404.
For a single-page application deployment, configure the server or host to send app routes to the application’s entry point. Vercel documents an SPA rewrite for this scenario: Vercel: Why is my deployed project giving 404?. TanStack Router’s deployment guide also identifies a missing refresh fallback as a common deployment issue: TanStack Router: Hosting. These are examples for their respective deployment contexts, not a universal rewrite rule. Server-rendered applications and framework-managed routes can require different handling; follow the deployment guidance for your framework and host.
Rank #2
If the build reports a missing module or file
Check the capitalization of both the file name and every import that refers to it. A local development machine may use a case-insensitive filesystem, while a production server may be case-sensitive. A mismatch such as importing ./Header.js when the file is named header.js can therefore pass locally and fail in production. Vite identifies incorrect casing as a possible cause of ENOENT or “Module not found” errors: Vite: Troubleshooting.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Compare the spelling in the import with the spelling actually committed in the repository, including directory names and file extensions. Correct the mismatch and rebuild; changing deployment routing or the public base path will not resolve a missing module caused by capitalization.
If production configuration or API requests behave differently
Inspect the failed API request and compare the deployed environment settings with the values expected by the production build. Check that variables are defined in the production environment, that their names follow the framework’s rules, and that the deployed build was created with the intended values. Do not copy a variable prefix from one framework into another.
Some frameworks substitute public environment values into client-side files during the build. For example, Next.js 14 documents that variables exposed through NEXT_PUBLIC_ are inlined into the JavaScript bundle during next build; changing their values after that build does not update the already-built app. See Next.js 14: Environment Variables. TanStack’s deployment guide shows the VITE_ prefix for Vite client variables: TanStack Router: Hosting. These examples are framework-specific. Never place secrets in variables exposed to client-side code; public values become available to users who can inspect the delivered JavaScript.
Rank #4
If a dynamic import fails after a new release
A release can leave a mismatch between cached HTML and the files available on the server. Vite documents a case where new deployment output has different chunk names but an older HTML document still refers to chunks that have since been removed. Check the failed chunk URL and whether the problem occurs for existing sessions or cached pages after deployment; compare it with the files in the current build. Vite discusses this failure mode in its troubleshooting guide.
Cache behavior and the right cache policy depend on the host and deployment setup. The symptom alone does not establish a single policy that will work everywhere; consult the provider’s guidance before changing cache settings.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Match the symptom to the next check
| Observed failure | Where to look first | Likely area to verify |
|---|---|---|
| Production build fails | Build output and host build logs | Build-time errors, production-only configuration, or dependencies |
| HTML loads but JavaScript or CSS returns 404 | Network panel and published files | Subdirectory base path or incorrect published output directory |
| In-app navigation works, but direct route or refresh returns 404 | Request URL, server response, and hosting rules | SPA fallback or rewrite, if this is a single-page app deployment |
“Module not found” or ENOENT |
Build log and import/file spelling | Filename or directory capitalization |
| Production API call fails or uses the wrong value | Network request and production environment settings | Framework-specific variable naming, production scope, or build-time substitution |
| Lazy-loaded module fails after deployment | Failed chunk URL, cached page, and current output files | Stale HTML referencing a removed chunk |
| Generated app opened from a file URL cannot load modules | Browser Console and address bar | Serve the output over HTTP instead of using file:// |
Verify the fix in the same conditions
- Rebuild with the corrected production configuration.
- Deploy the intended output directory using the host’s documented settings.
- Test the original failing condition: the exact route, refresh, asset, API call, or release scenario.
- Check Console and Network again. Confirm that the formerly failing request now succeeds and that the relevant error is gone.
The title alone cannot identify a single root cause. The framework, host, deployment path, and actual browser or build error determine which configuration applies.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
