< HTTP/1.1 203 Non-Authoritative Information

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.

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.

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

Related

• 200 OK
• 304 Not Modified
• Via
• Cache-Control: no-transform.