# 203 Non-Authoritative Information

> 203 means a proxy modified the origin response before passing it on. Learn when it is sent, how it differs from 200, caching rules and what clients should do.

Source: https://howhttpworks.com/status-codes/203
Last reviewed: 2026-10-04

> **TL;DR:** 203 is a 200 that tells you "the payload was modified by an intermediary and may not match the origin's." Only transforming proxies are supposed to send it, and you will rarely see it. Clients treat it as success.

## What it means

RFC 9110 §15.3.4 says an intermediary that applies a transformation to the content of a 200 response may change the status to 203 to tell the recipient the enclosed payload is not necessarily what the origin sent. The response is still a success and works like 200 everywhere else.

```http
GET /photo.jpg HTTP/1.1
Host: images.example.com

HTTP/1.1 203 Non-Authoritative Information
Content-Type: image/jpeg
Content-Length: 18342
Via: 1.1 mobile-optimizer
Warning: 214 mobile-optimizer "Transformation applied"
```

The `Warning` header with code 214 (Transformation Applied) was the older way to flag the same thing, but `Warning` is obsolete in current HTTP caching (RFC 9111 removed it), so do not expect it. The `Via` header is how you find the intermediary that touched the response.

## Handling it

- On the client, treat it as you treat 200. `fetch().ok` is true for all 2xx.
- If integrity matters (checksums, signatures, downloads that must be bit-exact), a 203 is the cue to verify against a trusted digest or fetch via a path without transformation, for example HTTPS end to end so no intermediary can alter content.
- On an intermediary you operate that rewrites bodies (image recompression, HTML minification, ad stripping), 203 is the correct signal, plus `Via`. Many send 200 and say nothing. Whatever you run, honour `Cache-Control: no-transform` from the origin, which forbids exactly these rewrites.

Two practical consequences follow from the cacheability. A 203 is stored and reused by caches exactly like a 200, so a transformed copy can outlive the transformation: if a mobile proxy recompressed an image at low quality and a shared cache kept it, desktop users may later receive the degraded copy. The origin's defence is `Cache-Control: no-transform`, which tells intermediaries not to change the payload, and `Vary` when the content legitimately differs by client.

The second consequence is for monitoring. Alerts that match on `status == 200` will silently ignore a 203, so use a 2xx range check. The reverse also applies: some tools log 203 as an anomaly when it comes from a CDN feature that rewrites HTML (minification, script injection). Compare the body hash against a direct-to-origin request to confirm what changed.

Because most transformation happens inside TLS-terminating CDNs under the origin owner's control, and plain-HTTP transcoding proxies have mostly disappeared, 203 is nearly extinct. If you see it, find out which hop produced it with `Via`, `Server` and `X-Cache`.

## Try it with curl

`203 Non-Authoritative Information` is only sent by a transforming proxy that modified an origin's `200`. Most proxies and CDNs never emit it. To check whether one sits in your path, send the request through it and look at the status and the `Via` header.

```bash
curl -i -x http://proxy.example.com:3128 http://example.com/
```

## Related

- [200 OK](https://howhttpworks.com/status-codes/200)
- [304 Not Modified](https://howhttpworks.com/status-codes/304)
- [Via](https://howhttpworks.com/headers/via)
- [Cache-Control](https://howhttpworks.com/headers/cache-control): `no-transform`.