304 Not Modified

The client's cached copy is still valid — the server sends headers only, no body, in response to a conditional request (If-None-Match with an ETag, or If-Modified-Since). This is HTTP caching working exactly as designed, saving the body transfer.

What usually causes it

  • Browser revalidating cached assets
  • CDNs revalidating against origin
  • API clients using ETags for efficient polling

How to debug and fix it

  1. 304 is not an error. If you see stale content, the bug is the caching headers (Cache-Control, ETag generation), not the 304 itself.
  2. If assets never 304 (always full 200), the server isn't sending ETag/Last-Modified — enable them to cut bandwidth.
  3. ETags that change on every response (timestamps or per-instance hashes baked in) silently defeat revalidation — make them content-derived.

Easily confused with

Debugging an API? Build and inspect requests, check response headers, or read the full status-code debugging guide.