203 Non-Authoritative Information
The response body comes from a transforming proxy, not directly from the origin server.
Quick Reference
| Category | 2xx Success |
|---|---|
| RFC | RFC 9110, Section 15.3.4 |
| Cacheable | Yes — same rules as 200 |
| Who sets it | Transforming proxies, not origin servers |
| Practical usage | Rare in modern web; more common in carrier/ISP proxy infrastructure |
What 203 Non-Authoritative Information Means
HTTP 203 Non-Authoritative Information signals that the response body is not the exact body returned by the origin server. A transforming proxy — a proxy that modifies the content of responses in transit — uses 203 to warn clients that the data has been altered. The origin server returned 200, but the proxy changed something before forwarding the response.
RFC 9110 defines this specifically: a proxy that transforms the payload should change the status from 200 to 203 so the client knows the data is not an unmodified copy from the source. This is a transparency mechanism: the client (or developer debugging the client) can see that an intermediary changed the response.
Without 203, a transforming proxy could silently modify responses and the client would have no way of knowing. Clients that need the exact origin response (security-sensitive applications, data integrity checks) can treat 203 as a warning flag.
What Transforming Proxies Do
A transforming proxy sits between the client and the origin server and modifies HTTP traffic. Common transformations that warrant a 203 response:
Image Compression
Mobile carrier gateways often compress images to reduce bandwidth for mobile users. The origin returns a 200 with a 500 KB JPEG. The carrier proxy recompresses it to 150 KB at lower quality and should return 203 to signal the modification. In practice, carriers often return 200 anyway, which is a spec violation.
Content Translation or Transcoding
An enterprise proxy that translates text from one language to another, or converts a PDF response to HTML for accessibility, is a transforming proxy. The content is substantively different from what the origin sent.
Annotation and Augmentation
Some security or parental-control proxies inject warning banners into HTML responses before forwarding them. A proxy that adds a “this site may contain adult content” header frame to an HTML page has transformed the response.
Format Conversion
A proxy that converts JSON responses to XML for a legacy client that can only consume XML has transformed the response. The data is equivalent but the format differs from what the origin sent.
Origin Servers and 203
An origin server should not return 203. If a server wants to indicate that the data it is returning comes from a third-party source or may not be up-to-date, there are better mechanisms: include a Warning header, document the API’s data freshness policy, or return appropriate metadata in the response body.
The original intent of 203 was strictly for proxies. However, some APIs have repurposed it to mean “this data comes from a cache or third-party source, not our live database.” This is technically a misuse of the status code but is not uncommon in practice. If you encounter 203 from an API that is not a proxy, check the API documentation for their interpretation.
203 in Modern Web Infrastructure
HTTPS has significantly reduced the frequency of transforming proxies. When traffic is encrypted end-to-end, a middlebox proxy cannot inspect or modify the content without breaking the TLS handshake. This means modern web applications over HTTPS rarely encounter 203 in production traffic.
Where 203 does still appear:
- Corporate proxies with TLS inspection (SSL interception) that rewrite responses for security scanning or data loss prevention.
- Mobile carrier networks that still perform HTTP-level content optimization for 2G/3G devices.
- Enterprise API gateways that enrich or filter API responses before forwarding them to clients.
- Reverse proxies configured to add headers, modify HTML, or inject scripts — though these typically return 200 rather than the correct 203.
Relationship to the Warning Header
Historically, HTTP included a Warning header (RFC 7234) that proxies could use to annotate transformed or stale content. Warning codes like 214 (Transformation Applied) served a similar purpose to 203. The Warning header was deprecated in RFC 9111 and is no longer part of current HTTP specifications.
203 remains the clean mechanism for a proxy to signal transformation: change the status code rather than adding a deprecated header. Modern proxy implementations that transform content should use 203 if they want to be transparent about the transformation.
203 vs Related Status Codes
| Code | Source of data | Modified in transit? |
|---|---|---|
| 200 OK | Origin server directly | No |
| 203 Non-Authoritative | Origin server, via transforming proxy | Yes — proxy modified content |
| 304 Not Modified | Client’s own cache | N/A (no body) |
| 502 Bad Gateway | Upstream failed — proxy could not get a response | N/A |
Frequently Asked Questions
Should my API return 203?
Almost certainly not. 203 is intended for transforming proxies, not origin servers. If your API wants to signal that data comes from a third-party or secondary source, use a response header or body field to convey that information. Returning 203 from an origin server is technically a misuse and will confuse clients that follow the spec.
Is 203 the same as 200?
Functionally similar — both indicate success and both have a body. The difference is provenance: 200 means the body came unmodified from the authoritative source; 203 means a proxy changed the body in transit. Caching rules are the same for both.
Why do I rarely see 203 in practice?
HTTPS prevents transparent proxies from inspecting and modifying traffic without client awareness. The vast majority of modern web traffic uses HTTPS, so transforming proxies cannot function without TLS interception, which breaks the TLS chain of trust and is typically visible to security-conscious applications.
Can a CDN return 203?
A CDN that serves cached content without modification should return 200 (not 203) from the cache, with appropriate Age and X-Cache headers. If a CDN transforms the content (compresses images, minifies HTML), it should technically return 203 but most CDNs return 200 for simplicity and because the transformation is a feature the origin operator opted into.