203 Non-Authoritative Information 2xx
The request succeeded, but the returned metadata is from a transforming proxy rather than the origin server.
What does 203 mean?
A 203 Non-Authoritative Information response means the request succeeded — functionally similar to 200 — but a proxy sitting between the client and the origin server has modified the response's metadata (headers, and possibly the content itself) before passing it along. The "non-authoritative" framing signals "this is what you're getting, but it's not necessarily exactly what the origin server originally sent — something in the middle changed it."
This is one of the rarest status codes in everyday use — most proxies and CDNs that modify responses (adding caching headers, compressing content, injecting analytics, etc.) don't bother changing the status code from 200 to 203, even though 203 exists precisely for this scenario.
How a 203 behaves
- It's functionally treated like 200 by most clients — the practical difference (response was modified by an intermediary) doesn't usually change how a client processes the response
- It can carry a body, same as 200
- It's cacheable, similar to 200
Common scenarios
If you're operating infrastructure:
- A transforming proxy (one that modifies responses — e.g., adding tracking pixels, compressing images, rewriting content for accessibility/translation) could theoretically use 203 to signal "this response has been altered from what the origin sent" — though in practice, most such proxies don't change the status code
If you're calling an API:
- You're extremely unlikely to encounter 203 from typical APIs — if you do, it may indicate the response passed through some kind of content-modifying proxy/gateway
If you're a website visitor:
- Not applicable — invisible in normal browsing
203 vs 200
| 200 OK | 203 Non-Authoritative Information | |
|---|---|---|
| Source of metadata | Directly from the origin server, unmodified | Modified by an intermediary (transforming proxy) before reaching the client |
| Practical handling | Standard success | Treated essentially the same as 200 by most clients |
Real-world examples
203 is genuinely one of the least-used status codes in the entire registry — even proxies and CDNs that do modify responses (compression, header rewriting, content transformation) overwhelmingly leave the status code as 200 rather than switching to 203, since the practical benefit of distinguishing "modified by a proxy" vs. "straight from origin" rarely matters to clients.
SEO implications
None of practical significance — search engines treat 203 essentially the same as 200 if encountered at all, which is rare.
FAQ
How is 203 different from 200 in practice?
For most clients, it isn't — both indicate success, and 203 simply adds the nuance "this response was modified by an intermediary." Few clients change their behavior based on this distinction.
Why would a proxy use 203 instead of just 200?
To be transparent that the response isn't exactly what the origin server sent — useful in theory for clients that care about response authenticity/provenance, though in practice this level of transparency is rarely implemented via status code changes.
Is 203 deprecated?
No, it remains a valid, defined status code — it's just rarely used in practice, as most transforming intermediaries don't bother distinguishing their modified responses from origin responses via the status code.
Should I implement 203 in my own proxy/API?
Unless you have a specific reason to signal "this response was modified in transit" to clients that would act on that information, there's little practical benefit — 200 is universally understood and won't cause any client confusion.
Fun fact
203 might be the status code with the largest gap between "officially defined and has a clear meaning" and "actually used in the wild" — it's a good illustration of how not every theoretically-useful piece of a specification ends up being adopted in practice, even when implementing it would be straightforward.