Compress Middleware
Compress Responses Before Sending to Clients The Compress middleware supports Gzip, Brotli, and Zstandard compression. The activation of compression and the compression method choice rely on the request’sAccept-Encoding header.
Configuration Examples
Enable Compression
Compression with Excluded Content Types
Compression with Specific Encodings
When Compression Occurs
Responses are compressed when all these criteria are met:- The
Accept-Encodingrequest header containsgzip,br,zstd, and/or*(with or without quality values) - The response is not already compressed (no
Content-Encodingheader) - The response
Content-Typeis not excluded (or is included if usingincludedContentTypes) - The response body is larger than the minimum configured bytes (default: 1024)
If the
Accept-Encoding header is absent and no defaultEncoding is configured, the response won’t be compressed. If present but empty, compression is disabled.Configuration Options
List of content types to exclude from compression. Compared case-insensitively with whitespace ignored.
The
excludedContentTypes and includedContentTypes options are mutually exclusive.gRPC (
application/grpc) is never compressed.List of content types to include for compression. Only responses with these content types will be compressed.
The
excludedContentTypes and includedContentTypes options are mutually exclusive.Minimum response body size in bytes required for compression.
When data is sent to the client on flush (e.g.,
Transfer-Encoding: chunked), this configuration is ignored and data is compressed immediately.Default encoding if the
Accept-Encoding header is not present or contains a wildcard (*).No fallback occurs when the header value is empty or unsupported.List of supported compression encodings. Valid entries are
gzip, br (Brotli), and zstd (Zstandard).The order sets priority - the top entry has the highest priority.