I recently encountered a puzzling issue on Windows Server 2019 running IIS with ASP.NET applications. Static HTML files displayed emoji characters perfectly, but the same emojis in ASPX pages rendered as gibberish - question marks, boxes, or bizarre character combinations that looked like hieroglyphics.
Here's what made this particularly confusing: the diagnostic data showed everything should be working. The HTTP headers were sending Content-Type: text/html; charset=utf-8, the Response.ContentEncoding was set to UTF-8, and the ASPX files themselves were saved as UTF-8 in Visual Studio. Yet Emojis still appeared broken.
The Investigation
To understand what was happening, I created a simple test page:
<%@ Page Language="C#" AutoEventWireup="true" %>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Emoji Test</title>
</head>
<body>
<h1>Emoji Rendering Test</h1>
<div style="font-size: 2em;">
😀 🎉 ❤️ 🔥 💻 ✅
</div>
<pre>
Response Encoding: <%= Response.ContentEncoding.WebName %>
Charset: <%= Response.Charset %>
ContentType: <%= Response.ContentType %>
</pre>
</body>
</html>
The diagnostic output showed:
Response Encoding: utf-8
Charset: utf-8
ContentType: text/html
Everything indicated UTF-8 was being used, yet the emojis displayed as garbled text. The same HTML content in a static html file worked perfectly.
Understanding the Root Cause
The issue lies in how ASP.NET reads ASPX files from disk before processing them. There are three distinct encoding points in the ASP.NET pipeline:
- File Encoding: How ASP.NET reads the ASPX file from disk
- Request Encoding: How ASP.NET interprets incoming request data
- Response Encoding: How ASP.NET encodes the output sent to browsers
Even though Visual Studio saves ASPX files as UTF-8 by default, ASP.NET on Windows Server doesn't assume this. Instead, it defaults to reading files using the system's ANSI code page - which is Windows-1252 on most Western Windows installations.
Here's what happens when ASP.NET reads a UTF-8 file as Windows-1252:
UTF-8 bytes for 😀: 0xF0 0x9F 0x98 0x80
Read as Windows-1252: ð (0xF0) Ÿ (0x9F) ˜ (0x98) € (0x80)
Result: Mojibake - "😀" or similar gibberish
The corruption occurs at the file reading stage, before any response encoding takes place. The already-corrupted characters are then faithfully encoded as UTF-8 and sent to the browser, preserving the corruption.
The Solution
The fix is surprisingly simple - tell ASP.NET to read ASPX files as UTF-8 by adding the fileEncoding attribute to your web.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<globalization fileEncoding="utf-8" />
</system.web>
</configuration>
That's it. You don't need to setrequestEncoding or responseEncoding if they're already defaulting to UTF-8. The fileEncoding attribute specifically controls how ASP.NET reads your ASPX, ASCX, and ASAX files from disk.
Testing the Fix
To isolate which globalization attribute was actually fixing the issue, I created separate test configurations:
<!-- Test 1: Only requestEncoding -->
<globalization requestEncoding="utf-8" />
<!-- Result: Emojis still broken -->
<!-- Test 2: Only responseEncoding -->
<globalization responseEncoding="utf-8" />
<!-- Result: Emojis still broken -->
<!-- Test 3: Only fileEncoding -->
<globalization fileEncoding="utf-8" />
<!-- Result: Emojis work! -->
Only the fileEncoding attribute fixed the issue, confirming that the problem was occurring when ASP.NET read the files from disk.
Key Lessons
1. Default Encodings Vary by Context
Windows Server editions often have different defaults than Windows desktop versions. The server OS prioritizes compatibility with legacy enterprise applications, which means defaulting to Windows-1252 rather than UTF-8.
2. Diagnostic Output Can Be Misleading
The Response.ContentEncoding property shows what encoding will be used for output, not what encoding was used to read the source file. This can lead to confusion when troubleshooting, as all the diagnostic data may show UTF-8 while the actual problem occurs earlier in the pipeline.
3. Static vs Dynamic Content
Static files bypass ASP.NET processing entirely. IIS serves them directly, respecting their actual encoding. This is why the same HTML file with emojis works fine as a .html file but breaks as an .aspx file - they follow completely different processing pipelines.
4. The Importance of Explicit Configuration
Rather than relying on defaults, explicitly configure encoding at all levels:
<configuration>
<system.web>
<globalization
fileEncoding="utf-8"
requestEncoding="utf-8"
responseEncoding="utf-8" />
</system.web>
</configuration>
5. Visual Studio vs Runtime Behavior
Visual Studio may save files as UTF-8, but this doesn't guarantee the runtime will read them as UTF-8. Always verify both the file encoding and the runtime configuration:
// To check file encoding in Visual Studio:
// File -> Save As -> Save with Encoding -> UTF-8
// To verify at runtime:
System.Text.Encoding.Default.WebName // Shows system default
Response.ContentEncoding.WebName // Shows response encoding
Additional Considerations
Font Support
Even with correct encoding, Windows Server may lack emoji fonts. The Segoe UI Emoji font from Windows 10/11 may need to be installed for full emoji support:
# Check for emoji font
Get-ChildItem C:\Windows\Fonts\*emoji*
# If missing, copy from Windows 10/11:
# C:\Windows\Fonts\seguiemj.ttf
HTTP Headers
While not the issue in this case, always verify actual HTTP headers using browser developer tools rather than relying on server-side diagnostics:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Results
This was the before:
This was after the web.config update, notice the response encoding is idential:
Conclusion
The emoji rendering issue in ASP.NET on Windows Server stems from a mismatch between file encoding and how ASP.NET reads those files. While files may be saved as UTF-8, ASP.NET defaults to reading them as Windows-1252 unless explicitly configured otherwise. The single-line fix - adding fileEncoding="utf-8" to web.config - resolves the issue by ensuring ASP.NET correctly interprets UTF-8 encoded ASPX files.
This issue highlights the importance of understanding the full encoding pipeline in web applications and not making assumptions about default behaviors, especially in server environments where backward compatibility often takes precedence over modern standards.