Expires

The HTTP Expires response header specifies a date and time after which the response is considered stale.

Usage

The Expires header provides an absolute timestamp indicating when a cached response loses freshness. Caches compare this timestamp against the current time to decide whether the stored copy is still usable.

The Cache-Control max-age directive supersedes Expires when both are present. Because max-age uses a relative seconds value instead of an absolute Date, the directive avoids clock-skew problems between servers and caches. Modern Caching policies rely on Cache-Control as the primary freshness mechanism, with Expires serving as a fallback for older caches lacking max-age support.

A value of 0 or an invalid date signals the response is already stale. Caches treat the entry as expired immediately, forcing revalidation or a fresh fetch on the next request.

The timestamp follows the same IMF-fixdate format used by the Date header:

Expires: <day-name>, <day> <month> <year>
  <hour>:<minute>:<second> GMT

Example

A response expiring on a Wednesday at 08:00 UTC. Any cache holding this response after the specified time treats the copy as stale.

Expires: Wed, 01 Jun 2025 08:00:00 GMT

A response marked as already expired. Setting the value to 0 forces caches to revalidate on every request.

Expires: 0

An Expires header paired with Cache-Control for backward compatibility. The max-age directive takes precedence, giving the response a one-hour freshness lifetime regardless of the Expires timestamp.

Cache-Control: max-age=3600
Expires: Thu, 01 Jan 1970 00:00:00 GMT

Takeaway

The Expires header sets an absolute timestamp for response freshness. The Cache-Control max-age directive supersedes Expires in modern implementations, but the header remains useful as a fallback for legacy caches.

See also

• RFC 9111: HTTP Caching
• Cache-Control
• Caching
• Date
• HTTP headers