Date: when the response was generated
Date is the time the response message was generated, in GMT. Caches use it as the origin point for every freshness calculation, so a wrong clock produces wrong caching.
At a glance
- Direction
- Response, and permitted on requests that carry a body.
- Defined in
- RFC 9110
- When absent
- A cache substitutes the time it received the response, which quietly shifts every freshness calculation.
- Format
- IMF-fixdate in GMT, for example Sun, 06 Nov 1994 08:49:37 GMT
- May be omitted
- Only by a server with no working clock, and on 1xx and 5xx responses
- Used to compute
- Response age, and therefore remaining freshness against max-age
- Not the same as
- Last-Modified, which describes the content rather than the message
In detail
Date describes the message, not the content. It is stamped when the response is generated, which for a cached response is the moment the origin produced it rather than the moment the cache handed it over. That distinction is what makes the freshness arithmetic work: a cache compares its own clock with this value and the Age header to decide how much of max-age is left.
The format is the fixed length GMT form and nothing else is acceptable. Two other formats appear in older specifications and receivers are expected to parse them, but senders must use this one. Everything is fixed width, the day and month names are English abbreviations, and the zone is always the literal GMT.
A wrong server clock has effects that look like anything except a clock problem. A Date in the future makes caches treat responses as newer than they are, cookies with an Expires date can be discarded immediately, and signed requests that check a timestamp window start failing intermittently as the drift crosses their tolerance.
Only a server with no reliable clock may omit the header, and 1xx and 5xx responses are also exempt. Everything else should carry it, since a missing Date forces every cache on the path to substitute its own arrival time, which is how two intermediaries end up disagreeing about when a response expires.
Examples
HTTP/1.1 200 OK
Date: Mon, 03 Feb 2025 10:00:00 GMT
Age: 120
Cache-Control: max-age=600Generated at 10:00, cached for two minutes already, so eight minutes of freshness remain.
curl -sI https://example.com | grep -i '^date:' && date -uThings that catch people out
- The value must be GMT. Sending a local time zone, even correctly labelled, produces a header many clients will not parse.
- Date is not Last-Modified. Confusing them makes a cache think a static file changed on every request, because the message time changes every time.
- Clock drift on one machine in a load balanced fleet gives that machine inconsistent caching behaviour, which is close to impossible to reproduce from a single client.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →Age: how long a cached response has been sitting there
What the Age header counts, how it combines with max-age to give remaining freshness, and how to use it to tell a cache hit from a miss at the edge.
Cache-Control: directives for browsers and shared caches
Every Cache-Control directive that matters, the difference between no-cache and no-store, and how to cache immutable assets forever without breaking deploys.
Last-Modified: timestamps as a weak validator
The exact date format Last-Modified requires, why one second resolution makes it a weak validator, and how caches use it to guess freshness.
Expires: the older way to set a freshness lifetime
What Expires does, why Cache-Control max-age overrides it, what an invalid date such as 0 means to a cache, and whether it is still worth sending.
Accept: asking for a media type, with preferences
How the Accept header expresses preferences with q values, how servers pick a representation, and what to return when nothing on the list can be produced.
Accept-Encoding: negotiating gzip, br and zstd
Which compression tokens clients send, how identity and the wildcard behave, why the response needs Vary, and how to test whether compression is really on.
Tools for this
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body