What is the difference between Cache-Control and Expires?

Both can communicate freshness, but they express it differently. Cache-Control uses directives; for example, max-age=3600 says the response is fresh for 3,600 seconds from when it was generated at the origin. Expires instead supplies a date and time after which the response is considered stale. [S1] [S2]

A useful shorthand is: max-age is a duration, while Expires is a timestamp. Cache-Control can also carry directives for other caching behavior, so it does more than provide a freshness value. How a response is handled depends on the directives, the kind of cache, and HTTP rules. [S1]

For example, if an origin generates a response at 12:00 and includes Cache-Control: max-age=3600, that directive expresses one hour of freshness from that generation time. This is an illustration of the stated duration rule, not a guarantee that every cache will handle the response identically.

They do not have to agree, but it is clearer to configure them consistently when you include both. When Cache-Control: max-age and Expires are both present, max-age takes precedence for freshness. So, if the duration and date imply different freshness periods, do not treat Expires as overriding max-age. [S2]

A simple example, with placeholders for the origin’s actual generation time and corresponding date, is:

Cache-Control: max-age=3600 Expires: [date and time corresponding to one hour after generation]

Here both values express a one-hour freshness period. If the Expires placeholder instead represents a later time, the documented precedence still means max-age governs when both are present. This example shows the relationship between the headers; it does not establish how a particular browser or intermediary handled a specific response.

They are related, but they are not interchangeable in every circumstance. Expires was used for freshness in HTTP/1.0, while Cache-Control provides directives such as max-age and can specify other caching behavior. [S2] You can read an Expires date as an absolute freshness cutoff, and a max-age value as a freshness duration.

Whether to include both depends on the policy you want to express and the systems that need to interpret the response. The available information establishes that max-age takes precedence over Expires when both are present; it does not establish which header is required for your particular application, deployment, or audience. Avoid assuming that adding Expires changes behavior when a controlling max-age is also present.

Read the directives and identify the cache context before drawing a conclusion. In particular, s-maxage applies to shared caches and, when present, overrides max-age or Expires there. [S1] That means a response can have one freshness instruction relevant to shared caches and another general freshness value, rather than one number that answers every caching question.

A practical review might look like this:

1. Record the complete Cache-Control value, including any max-age or s-maxage directive.
2. Record Expires, if present, and note that it supplies a date and time.
3. Identify whether you are asking about a browser or a shared cache.
4. Apply the documented precedence for that context: max-age over Expires when both are present; s-maxage over max-age or Expires for shared caches when present. [S1] [S2]
5. If the observed behavior remains unclear, gather the response headers and relevant request context for a qualified HTTP or platform specialist to review.

These headers explain freshness policy, but the excerpts do not establish the behavior of a particular cache product or explain every HTTP caching rule. Use the actual response and cache context rather than inferring a complete diagnosis from one header.