Accept-Encoding Header

TL;DR: Tells servers what compression formats your client supports (gzip, brotli, deflate). Enables compressed responses to reduce bandwidth and improve performance.

What is Accept-Encoding?

The Accept-Encoding header tells the server what compression algorithms your client can decompress. It’s like saying “I can handle compressed files in ZIP or RAR format” so the server can send smaller, faster responses.

This header is crucial for web performance—compressed responses can be 60-80% smaller than uncompressed ones.

How Accept-Encoding Works

Client advertises compression support:

GET /api/posts HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br
```text

**Server responds with compressed content:**

```http
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 1247

[Compressed JSON data...]

Common Compression Algorithms

gzip

Most widely supported compression format:

Accept-Encoding: gzip
```text

- **Compression:** ~70% size reduction
- **Support:** Universal (all browsers and servers)
- **Speed:** Fast compression and decompression

### Brotli (br)

Modern, more efficient compression:

```http
Accept-Encoding: br

• Compression: ~20% better than gzip
• Support: Modern browsers (Chrome 50+, Firefox 44+)
• Speed: Slower compression, fast decompression

deflate

Older compression format:

Accept-Encoding: deflate
```text

- **Compression:** Similar to gzip
- **Support:** Widely supported but less common
- **Usage:** Mostly legacy systems

## Quality Values and Preferences

### Basic Preference Order

```http
Accept-Encoding: br, gzip, deflate

Prefer Brotli, then gzip, then deflate.

With Quality Values

Accept-Encoding: br;q=1.0, gzip;q=0.8, deflate;q=0.6
```text

- Brotli most preferred (q=1.0)
- gzip second choice (q=0.8)
- deflate third choice (q=0.6)

## Real-World Examples

### Modern Browser

```http
Accept-Encoding: gzip, deflate, br

API Client

Accept-Encoding: gzip
```text

### Bandwidth-Conscious Client

```http
Accept-Encoding: br;q=1.0, gzip;q=0.9, deflate;q=0.8

Compression Effectiveness

Content Type	gzip Reduction	Brotli Reduction
HTML	70-80%	75-85%
CSS	75-85%	80-90%
JavaScript	65-75%	70-80%
JSON	70-80%	75-85%
Images	0-5%	0-5%

Best Practices

For Clients

// ✅ Always request compression
fetch('/api/data', {
  headers: {
    'Accept-Encoding': 'gzip, deflate, br'
  }
})
```text

### For Servers

```javascript
// Enable compression for text content
app.use(
  compression({
    filter: (req, res) => {
      return compression.filter(req, res)
    }
  })
)

Performance Impact

1MB JSON response:
- Uncompressed: 1MB transfer
- gzip: ~300KB transfer (70% savings)
- Brotli: ~250KB transfer (75% savings)

Related Headers

• Content-Encoding - Server’s compression choice
• Vary - Cache variation by encoding
• Accept - Content type preferences

Compression Priority and Quality Values

Browsers send quality values (q-values) with Accept-Encoding to express preferences when multiple formats are acceptable. A q-value of 1.0 is the highest priority, and 0.0 means the encoding is not acceptable. When no q-value is specified, the default is 1.0.

Modern browsers typically send Accept-Encoding: gzip, deflate, br without explicit q-values, meaning all three are equally acceptable. Servers should prefer Brotli when available because it achieves 15-25% better compression than gzip for text content, at the cost of slightly higher CPU usage during compression. For static assets served from a CDN, the compression cost is paid once and the result is cached, making Brotli the clear choice.

The identity encoding (no compression) is always implicitly acceptable unless the client sends identity;q=0. Servers should never compress already-compressed formats like JPEG, PNG, or ZIP, as the result is often larger than the original. Check the Content-Type before applying compression and skip binary formats.