Memento-Datetime

When a web archive returns a stored snapshot, the Memento-Datetime response header indicates the exact datetime when the resource was captured.

Table of Contents

Usage
Values
Example
A promise of immutability
See also

Usage

Web archives like the Wayback Machine, national libraries, and other preservation services store snapshots of web pages over time. The Memento-Datetime header appears in responses from these archives to communicate exactly when a particular snapshot was recorded. This is part of the Memento framework, which provides time-based access to prior versions of web resources.

When a client requests an archived version of a page, the archive server returns the stored snapshot along with Memento-Datetime set to the capture timestamp. This allows clients and tools to confirm which point in time the snapshot represents. The value follows the same HTTP-date format used by Date and Last-Modified, making parsing consistent with existing HTTP date handling.

The Memento framework introduces several related concepts: an original resource (the live page), a memento (an archived snapshot), a TimeGate (a resource negotiating by date), and a TimeMap (a listing of available mementos). The Memento-Datetime header identifies a response as a memento and pins the snapshot to a specific moment.

Values

The value is a single HTTP-date in the IMF-fixdate format, identical to the format used by the Date header.

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

Example

A response from the Wayback Machine for a page captured on September 29, 2010. The Memento-Datetime value records the exact moment the archival crawl stored this snapshot.

Memento-Datetime: Wed, 29 Sep 2010 08:58:15 GMT

A more recent capture from 2025 shows the same format. The timestamp confirms this is a snapshot taken during a May 2025 crawl of the target site.

Memento-Datetime: Fri, 09 May 2025 23:41:44 GMT

Archives return Memento-Datetime alongside a Link header pointing to the TimeMap and original resource. The Vary: accept-datetime header belongs to the TimeGate performing the negotiation. A snapshot served at its own address, distinct from the TimeGate, does not carry the field.

Memento-Datetime: Thu, 27 Dec 2012 19:25:48 GMT
Link: <http://example.re/>; rel="original", <https://web.archive.org/web/timemap/link/http://example.re/>; rel="timemap"

A promise of immutability

Memento-Datetime on a response is a commitment: the state shown will no longer change. The header marks an archived snapshot rather than a live resource, which makes the field the reliable machine signal separating an archive copy from the page under archiving.

The protocol splits roles across two resources, and the Vary header separates them on the wire. A TimeGate negotiates over time, accepting an Accept-Datetime request header and answering with a redirect to the nearest snapshot, always carrying Vary: accept-datetime. A snapshot at its own address carries Memento-Datetime without varying on datetime, while a TimeGate answering with the snapshot directly, in 200-style negotiation, carries both headers on one response. The Wayback Machine implements the exchange exactly this way, with a Link header naming the original, timemap, and timegate relations at each step.

Archives also republish what the origin sent. Wayback responses carry the original headers under an x-archive-orig- prefix, so the ETag and Last-Modified values of the page as captured survive inside the snapshot response.

The specification is an Informational RFC rather than a standard, a distinction most references miss.