HTTP Status Codes
HTTP 304 Not Modified
Not Modified — cached copy on client remains valid and fresh
Status 304 Not Modified tells the client that its cached copy is still fresh, so the response carries updated headers but no body. The exchange is the success case of a conditional request: the client sent a validator such as If-None-Match or If-Modified-Since and nothing had changed. The server repeats the header fields the matching 200 response would have carried — ETag, Cache-Control, Expires, Vary among them — so the client can refresh its cache metadata before reusing the stored body. Skipping the transfer saves bandwidth on heavy assets; the code is normal traffic, not an error.
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 cached copy on client remains valid and fresh.
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
The 304 response is generated when a client makes a conditional request using validators such as 'If-None-Match' (comparing entity tags / ETags) or 'If-Modified-Since' (comparing timestamps). If the server determines the resource has not changed, it returns 304 without a body.
Conditional headers
This mechanism is fundamental to web performance. The response includes fresh cache-control and metadata headers, allowing the client to update its local cache expiration without re-downloading existing content.
No response body
An origin server evaluates preconditions before performing the method: a false If-None-Match condition yields 304 for GET or HEAD requests and 412 Precondition Failed for every other method. If-None-Match also takes precedence — a request that carries it must have its If-Modified-Since condition ignored, because entity tags are treated as the more accurate validator.
Related HTTP Codes
Nearby HTTP status codes help clarify how 304 differs inside the same response family.
304
Not Modified
cached copy on client remains valid and fresh
200
OK (Success)
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
origin server requires the request to be conditional
Common Causes
Conditional GET request matching the stored ETag validator via If-None-Match
A common condition that triggers a 304 response when the web server evaluates the transaction.
Conditional request matching the last modification timestamp via If-Modified-Since
A common condition that triggers a 304 response when the web server evaluates the transaction.
Browser cache revalidation confirming unchanged static assets
A common condition that triggers a 304 response when the web server evaluates the transaction.
A no-cache directive in the stored response, which requires successful validation against the origin before every reuse
A common condition that triggers a 304 response when the web server evaluates the transaction.
Typical Scenarios
A web browser revalidates cached CSS, JavaScript, and images using ETag identifiers
An API client periodically checks a resource endpoint without downloading identical payload bodies
A CDN edge proxy validates cached assets with the origin server before serving them to edge clients
A continuous integration job re-fetches an unchanged build artifact, and the artifact server skips the payload with a 304
What To Know
A 304 response is a positive optimization signal indicating successful cache revalidation. It requires no remedial action and confirms that bandwidth was saved.
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.
If-None-Match. The caching rules require a recipient to ignore If-Modified-Since when the request carries an entity-tag condition, because the ETag comparison is treated as the more accurate test.
Only for GET and HEAD. When a false precondition arrives with another method, such as PUT, the server responds with 412 Precondition Failed instead.
A 304 cannot carry content. It tells the client to keep using the representation it already stored, so HTTP libraries and middleware need to read the cached body rather than expect a fresh payload.