JS eval error on IIS server – fix for Azure & Windows deployments

When this error shows up

You're deploying a web app – could be a Node.js backend proxied through IIS, or an old-school ASP.NET app with client-side JavaScript that uses eval() or new Function(). Everything works fine on local dev, but once it hits the staging or production IIS server, you see this in the browser console: SCRIPT5: Access is denied (the JavaScript eval error). It usually happens when your JavaScript code tries to execute a dynamically constructed string from an AJAX response or from a server-generated variable.

Had a client last month who built a dashboard that parsed JSON payloads from a REST API. Worked perfectly on their Mac dev machine. Deployed to Azure App Service – boom, eval error on every page load. Took me 15 minutes to track it down.

Root cause (plain English)

IIS is stricter than your local dev server about security zones. When your JavaScript code calls eval(), it's essentially asking the browser to run a code string. IIS, by default, sends the JavaScript file with a Content-Type: application/x-javascript or sometimes even text/plain if the file extension isn't properly mapped. The browser then sees that the script was delivered from a different context (or without the proper charset), and it blocks the execution of eval() to prevent cross-origin scripting attacks.

Another common trigger: missing charset in the Content-Type header. If IIS serves your .js files without charset=utf-8, some older browsers (and even modern ones in strict mode) will refuse to execute eval() on that script. I've seen this on Windows Server 2016 and 2019 with IIS 10.

Fix (numbered steps)

1. Check the Content-Type header for .js files. Open IIS Manager, select your site, double-click MIME Types. Make sure .js is mapped to application/javascript (not application/x-javascript or text/plain). If it's wrong, edit it.
2. Add charset to the .js MIME type. In IIS Manager, right-click the .js MIME type entry, choose Edit, then in the Value field, change it to application/javascript; charset=utf-8. This is the fix that worked for my Azure client.
3. Alternatively, use web.config. If you can't access IIS Manager, add this to your site's web.config inside the <system.webServer> block:

   <staticContent>
     <mimeMap fileExtension=".js" mimeType="application/javascript; charset=utf-8" />
   </staticContent>

4. Clear the server cache. Run iisreset from an admin command prompt to force IIS to reload the config. Or in IIS Manager, click Restart on the server node.
5. Test with a simple eval. Create a HTML page with <script>eval('var x=1; console.log(x)');</script>. Open it in the browser and check the console. If no error, your app-level code is fine.

What to check if it still fails

• Are you using Azure App Service? Go to the Azure portal, your app's Configuration > General Settings. Set Platform to 64-bit if your app uses native modules. Also add an application setting WEBSITE_LOAD_USER_PROFILE = 1 for Node.js apps.
• Check if your JavaScript file is being served from a CDN. CDNs sometimes alter Content-Type. If the file is minified and served from a different domain, the browser's same-origin policy can block eval. Either host it locally or add proper CORS headers.
• Look for HTTP response headers. Use your browser's network tab to inspect the .js file request. If you see X-Content-Type-Options: nosniff without a proper charset, that's your problem. Add <httpProtocol> <customHeaders> <remove name="X-Content-Type-Options" /> </customHeaders> </httpProtocol> to web.config if you must, but better to fix the charset.
• If nothing works, replace eval(). Honestly, modern JavaScript doesn't need eval. Use JSON.parse() for data, or Function() constructor for dynamic code. That avoids the security zone issue entirely. I've told devs before: if you're using eval in 2024, you're probably doing something wrong anyway.

Quick note: This error is almost never about the JavaScript syntax itself. It's the server configuration. Nine times out of ten it's a Content-Type mismatch. Don't waste time debugging your JS code – check IIS headers first.