HTTP Status Codes
HTTP 304 Not Modified
Not Modified — the stored representation is still current, so no body is sent
A 304 Not Modified response tells the client that a stored representation is still valid, so the server does not send the body again. It appears in conditional requests that use validators such as ETag or modification time to decide whether a fresh transfer is necessary.
Visual summary
A quick reference view of how HTTP 304 confirms that a stored representation is still current, so the client reuses it instead of downloading the body again.
What 304 Means
The shortest useful reading of this status code.
Not Modified means the stored representation is still current, so no body is sent.
For cache validation, the key distinction is that 304 confirms an existing stored representation rather than transferring a fresh response body.
Quick read
Cached copy still valid
A 304 means the client should reuse its stored representation because the resource has not changed.
Technical Context
How this status behaves without turning the page into a repair guide.
Cache validation
A 304 is easiest to understand as a cache-validation response, not as a redirect and not as a conventional error. The request still reaches the origin or intermediary, but the server decides the client's stored copy is current enough to reuse, so no new representation body is transferred.
Conditional headers
That makes 304 closely related to other conditional-request signals such as 412 and 428. A 304 says the condition succeeded for reuse of an existing representation, while a 412 says a supplied condition evaluated false and a 428 says the server required a condition that was missing.
Related HTTP Codes
Nearby HTTP status codes help clarify how 304 differs inside the same response family.
304
Not Modified
the stored representation is still current, so no body is sent
200
OK
the request succeeded and the server returned the expected response
412
Precondition Failed
a conditional header did not match current resource state
428
Precondition Required
the server requires a conditional request before changing state
Common Causes
If-None-Match matches the resource's current ETag
The client already has a stored representation whose validator still matches the server's current version.
If-Modified-Since matches the resource's last modification time
Timestamp-based validation shows the stored copy is still current enough for reuse.
Browser validates cached scripts, styles, or images
The client rechecks cached assets and receives confirmation that no new transfer is needed.
API client rechecks unchanged data to avoid a full transfer
Conditional requests let integrations save bandwidth when the underlying representation did not change.
Typical Scenarios
A browser revisits a page and validates cached CSS and JavaScript before reusing them
An API client sends If-None-Match to avoid downloading unchanged data again
A proxy rechecks a stored resource and receives confirmation that the cached copy is still current
What To Know
A 304 usually points to normal validator-based caching rather than to a broken page. When many static assets return 304 while the document still renders correctly, the visible pattern fits healthy cache reuse instead of missing content or redirect behavior.
Frequently Asked Questions
Common interpretation questions about HTTP 304.
No. A 304 is generally a normal cache-validation response. It means the client can keep using its stored representation instead of downloading the body again.
No. It sits in the 3xx family, but it does not move the client to another URL. It only confirms that the existing cached copy is still valid.
Because the point of 304 is to avoid sending the representation again. The client already has the body and only needed confirmation that it has not changed.