About the Gzip Compression Behavior on Azure App Service

Background

When we deploy our web applications to Azure App Service, the Gzip compression header is sometimes enabled by default and sometimes missing. I wanted to run a few tests to better understand this behavior.

Gzip compression is controlled via the Content-Encoding HTTP response header. When a server sends compressed content, it returns:

Content-Encoding: gzip

in the response. The browser advertises that it supports compression by sending:

Accept-Encoding: gzip

This negotiation allows compatible servers to send smaller, compressed responses, which helps reduce bandwidth usage and improve page load times.

Goal

Identify under what conditions the Gzip compression header is automatically added by Azure App Service.
Determine whether we can manually change the default behavior to enable or disable Gzip on Azure App Service.

Test Method

Create a new ASP.NET Core 10.0 Razor Pages project in Visual Studio 2026 using the default template.
Deploy the same project to Azure App Service with different hosting configurations.
Browse the site and check whether gzip appears in the Content-Encoding response header.
If gzip is not present, add the Gzip compression middleware in code, redeploy, and check the response headers again.

The code used to enable Gzip compression in ASP.NET Core is:

// Add response compression with Gzip
builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<GzipCompressionProvider>();
});
builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
    options.Level = System.IO.Compression.CompressionLevel.Fastest;
});
// Use response compression (must be before static files)
app.UseResponseCompression();

Dockerfile used:

# See https://aka.ms/customizecontainer to learn how to customize your debug container
# and how Visual Studio uses this Dockerfile to build your images for faster debugging.
# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["GzipTest.csproj", "."]
RUN dotnet restore "./GzipTest.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "./GzipTest.csproj" -c $BUILD_CONFIGURATION -o /app/build

# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./GzipTest.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

# This stage is used in production or when running from VS in regular mode
# (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "GzipTest.dll"]

Test Result

All App Service instances were configured with HTTP/2 enabled.

Windows Container was not included in the test, as it is rarely used in most scenarios.

Plan	Deployment	Stack	Server Header	Gzip Enabled in Code	Gzip in Response Header
Windows	Code	ASP.NET Core 10.0	Microsoft-IIS/10.0	No	Yes
Linux	Code	ASP.NET Core 10.0	Kestrel	No	No
Linux	Code	ASP.NET Core 10.0	Kestrel	Yes	Yes
Linux	Container	ASP.NET Core 10.0	Kestrel	No	No
Linux	Container	ASP.NET Core 10.0	Kestrel	Yes	Yes

Controlling the Gzip Behavior

How to Disable Gzip on a Windows Plan

From the test results, only the Windows App Service plan enables Gzip compression by default at the server level. Azure currently does not expose a UI setting for this, but you can disable it using a small configuration trick.

First, open the Advanced Tools (Kudu) for your App Service.

Then open the Debug console and cd into the site directory.

Create a new file named applicationHost.xdt and click the pencil icon to edit its content.

Paste the following configuration and save the file:

<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <urlCompression xdt:Transform="Replace" doStaticCompression="false" doDynamicCompression="false" />
  </system.webServer>
</configuration>

Restart your web app.

After the restart, you should see that the Gzip compression header is no longer present in the responses.

What about Linux?

On Linux App Service, there is currently no platform-level setting to enable or disable Gzip compression. As the test results show, compression must be controlled by your application code (for example, using AddResponseCompression in ASP.NET Core).

However, in many scenarios you may not be able to modify the application code (legacy apps, third-party apps, etc.). In those cases, a practical approach is to place your app behind a load balancer or reverse proxy that supports compression, such as Azure Front Door, and configure compression rules there.

Conclusion

On Azure App Service:

Windows plans enable Gzip compression by default at the server level (IIS). You can disable it by adding a custom applicationHost.xdt transform file.
Linux plans (both code and container) do not enable Gzip by default. You must configure compression in your application (for example, via ASP.NET Core middleware) or offload it to an upstream service such as Azure Front Door.

If you cannot modify your application code on Linux, placing it behind Azure Front Door and enabling compression there is a straightforward and flexible solution.

Microsoft MVP for Azure