PageDate

The date printed on a page is just text — it can be wrong, missing, auto-updated to today, or quietly bumped when an old article is republished. PageDate doesn't trust any single source. It reads the page's machine-readable claims (JSON-LD datePublished, article:published_time and friends), checks the URL itself for a date pattern, and then asks the Wayback Machine when the page was first archived — a timestamp the page's author doesn't control.

Pasting an archive snapshot link works too. A link like web.archive.org/web/20130603…/https://example.com/page wraps the page you actually care about — PageDate unwraps it and dates the original URL, not the archive copy, and says so above the result. The snapshot timestamp in the link is kept as evidence: if the archive's index can't be reached, that capture still proves the URL was archived by then — reported honestly as "not necessarily the earliest snapshot". Nested archive-of-archive links are unwrapped down to the innermost page.

It also checks the site's own RSS/Atom feed (including JSON Feed). If the page declares a feed and that feed carries an entry for the exact URL being checked, the entry's publish date is strong evidence — feeds are typically generated from the CMS's original post date, so they sometimes preserve the true date even when the on-page date has been bumped. The honest limit: feeds usually list only a site's most recent posts, so this source mostly helps with recent content — when the page isn't in the feed, the evidence table says so.

The site's XML sitemap is scanned too (found via the Sitemap: lines of robots.txt, or the /sitemap.xml convention). If the checked page is listed with a <lastmod> date, that date joins the evidence table — but only as weak, for-your-information evidence: lastmod records when a page last changed, not when it was published, and many sitemap generators auto-bump it sitewide on every rebuild. It never moves the estimate; it can still be useful context, and when a page isn't in its own site's sitemap (or carries no date there), the table says so honestly.

For pages on Wikipedia and its sister wikis (Wiktionary, Wikisource, Commons, Wikidata and the rest), PageDate asks the one source nothing else has: the wiki's own revision history, via its public API. A wiki article's true "publication date" is its first revision — kept by the site's software, not embedded in editable page metadata — and it usually beats the archive by years: many early articles weren't captured by the Wayback Machine until long after they were written. Honest limits: renames carry history along, so the date belongs to the article's lineage, not necessarily its current title; a page that was deleted and recreated starts its history over; and the earliest 2001–2002 Wikipedia histories were partially reconstructed after a software migration, so a very early first revision is a floor, not gospel — the estimate says so when it applies.

PDF files get their own treatment: paste a link to a PDF — a report, a paper, a leaked document — and PageDate reads the metadata embedded inside the file: the document info dictionary's CreationDate and ModDate, and the XMP packet many exporters add, plus the title and author for the citation box. Two honesty rules apply. First, a PDF's creation timestamp records when the file was exported, not when it was put online — usually the same moment, but a report can be written months before it's published (and the timestamp comes from the author's own computer clock), so the estimate says so, and the Wayback Machine's first snapshot of the URL is the check on it. Second, the info dictionary and the XMP packet are normally written by the same exporter in the same save — when they agree, that's one source, not two, so PageDate never counts the pair as "independent signals agreeing". Limits, stated in the evidence table when they apply: an encrypted PDF's info strings are unreadable without the password, some PDFs store their info in compressed sections a byte-level scan can't read, and for very large files only the first chunk and the end of the file (where PDFs keep their metadata) are scanned.

Image files carry their own dates too: paste a link to a JPEG, PNG, WebP or TIFF and PageDate reads the metadata embedded inside the file — the EXIF DateTimeOriginal ("when the camera says the photo was taken"), the XMP dates editing tools write, PNG's eXIf and tIME chunks — plus the artist and description for the citation box. The honesty rules mirror the PDF branch, with one big extra: a camera timestamp dates the capture, not the posting. It is written by the camera's own clock, which can be wrong or was never set (implausible values like 1980 are shown but not believed); most cameras record local time with no timezone, so the time of day is only as good as the camera's settings; and the field is trivially editable. Two useful asymmetries, both stated in the result: most social platforms and many CDNs strip camera metadata on upload, so a surviving timestamp usually means you are looking at an original file rather than a re-shared copy — and its absence from a web-hosted image is normal, not suspicious. An archive snapshot from soon after the capture time is what raises confidence. GIF has no capture-date field at all, and HEIC/AVIF scanning is not supported yet — the evidence table says so. PageDate reads dates only; a photo's GPS coordinates and the rest of its metadata are noted as present but never displayed. To inspect everything a photo file on your own device carries — and download a clean copy with the metadata removed — use PixWash, a sibling tool that parses the file locally in your browser without uploading it.

Some URLs carry their own birth certificate: a post-ID timestamp. X/Twitter status IDs and Discord message IDs are snowflakes — the platform packs the creation time, to the millisecond, into the ID itself — and a Bluesky post's record key is a timestamp in disguise too. So are a TikTok video ID (its top 32 bits are plain unix seconds), a LinkedIn post's activity ID (top 41 bits, milliseconds since the Unix epoch), and an Instagram shortcode — which is the post's media ID written in a base64 alphabet, with a timestamp in its top bits (Meta reused the same scheme for Threads, so Threads post URLs decode identically — verified against archived Threads pages' own embedded timestamps). PageDate decodes all of these, which means it can date a post even after it has been deleted, and even when the platform blocks the fetch entirely: the ID was assigned at posting and cannot be edited afterwards. The honest limits: an ID alone cannot prove a post with that ID ever existed (a mistyped link decodes just as cleanly, so corroboration — an archive snapshot, or the page itself — is what raises confidence); tweets from before November 2010 predate snowflakes and carry plain sequential IDs, so they honestly yield nothing; Instagram gets two extra stated caveats — the platform never published its ID epoch, so the decode leans on the value web-archiving researchers estimated from 1,000 posts, and the ID marks when the media entered Instagram's systems, which can precede the post going public (observed up to an hour for videos, longer for drafts); and a Mastodon-style URL is dated with an explicit caveat, because the server's software cannot be confirmed from the URL shape alone.

The same trick works beyond social platforms. Several ID schemes used all over the web embed their creation time: a MongoDB ObjectId (the 24-character hex tokens many apps put in URLs — its first four bytes are plain unix seconds), a ULID, a version-1 or version-7 UUID, and a KSUID. When a URL's path, file name or query string carries one, PageDate decodes it — which can date an API record, a CMS entry or an uploaded file even after it has been deleted. The honest limits are stated in the result: unlike the platform decoders above, no hostname confirms the scheme — it is inferred from the token's shape alone, and a random token of the same shape can occasionally decode to a plausible-looking date (for a random 24-character hex string, about one time in eight lands in the believable window) — and the timestamp marks when the record was created in the site's systems, which can precede the content going public. So a shape-inferred ID alone stays low confidence; corroboration raises it. Version-4 UUIDs — the most common kind — are random and honestly yield nothing.

It also reads the dates a human would see: text like “Published May 3, 2019” or “Last updated June 2020” printed in the page body. Many pages carry no machine-readable metadata at all, and on others the printed date disagrees with the metadata — both cases show up in the evidence table. A printed date that merely repeats an existing machine-readable claim is not counted twice, so one byline can't masquerade as two independent sources. And because pages worth dating are written in every language, this works beyond English: “Опубликовано 13 июля 2006”, “Veröffentlicht am 3. März 2019”, “Publicado el 3 de mayo de 2019” are read as the claims they are — month names and publish/update wording in French, German, Spanish, Italian, Portuguese, Dutch, Polish, Czech, Russian, Ukrainian, Turkish, Romanian, Scandinavian and Indonesian, plus numeric forms: European 13.07.2006, year-first 2006. 07. 13., and CJK 2006年7月13日 / 2006년 7월 13일. One deliberate refusal: a slash date like 03/04/2019 reads March 4 in Boston and April 3 in London, so unless one field is unambiguously the day (25/12/2019), it is not treated as a claim at all rather than guessed at.

One more bound comes from the domain registration record (RDAP): no page can exist at an address before the domain itself was registered. That gives never-archived, metadata-free pages at least an honest floor — and it catches fabrication outright: a page claiming a 2009 date on a domain registered in 2022 gets flagged, because the content either first lived elsewhere or the date is invented. The registration date survives transfers between registrars; it only resets if a domain fully expired and was re-registered, which the warning says explicitly.

One printed statement outranks everything: an explicit “originally published on…” or “first published on…” line. That's the author deliberately telling you the content is older than the page it now lives on — common when an article is reposted to a new platform. When that stated date is clearly earlier than the page's own metadata, PageDate makes it the estimate and flags the page as reposted content: the metadata dates the posting, the statement dates the content, and the content's date is usually the one you wanted.

• High confidence — several independent signals agree, or an explicit publish claim is consistent with the first archive snapshot.
• Medium — one explicit machine-readable claim, nothing to corroborate it.
• Low — only weak signals (a date in the URL, generic date tags), or the claim contradicts the archive.
• "Online by" — the page claims nothing, but its first archive snapshot proves it existed by that date. The real publish date may be earlier.

If a page was archived before the date it now claims, PageDate flags it — that's the signature of date-bumping (republishing old content with a fresh date), which matters if you're citing, fact-checking, or ranking sources.

• A page never archived and carrying no metadata simply can't be dated from the outside. PageDate says so instead of guessing.
• The first archive snapshot is an upper bound — pages often exist long before a crawler finds them.
• Some sites block automated fetching; you'll still get the Wayback and URL evidence.
• Paywalled or JS-only pages may hide their metadata from any fetcher.

Drag this link — PageDate this page — to your bookmarks bar. Then, on any article you're reading, click it: PageDate opens in a new tab with that page's address filled in and the check already running. It's the one-click version of copy-paste-check, and it works in Chrome, Firefox, Edge and Safari. (If your bookmarks bar is hidden, press Ctrl/⌘+Shift+B first.) Don't click it here — drag it to your bookmarks bar, then use it on a page you want to date.

The bookmarklet is a one-line piece of JavaScript that only builds a link: it puts the current page's address into the # fragment and opens PageDate. Nothing is sent anywhere until the check itself runs, exactly as if you had pasted the URL by hand. Honest limits: a few sites ship a security policy strict enough to stop bookmarklets from running at all — on those pages nothing happens when you click; copy the address and paste it here instead. And if your browser blocks the new tab as a pop-up, the bookmarklet navigates the current tab instead, so it still works.

Prefer a real toolbar button that doesn't need the bookmarks bar visible? There's also a browser extension for Chrome, Edge and Brave — same one click, plus a right-click "PageDate this link" for dating an article before you even open it. It installs from a ~9 KB zip (not in the Web Store yet — the extension page explains the honest install steps), collects nothing, and its entire source fits on one screen.

Each case file walks through the evidence for one real page — captured, explained, and re-runnable live — and what it teaches about dating content on the web. New cases are announced in the Atom feed:

• Date-bumping: a 2013 guide that says 2026 — a famous CSS reference whose metadata claims a date thirteen years after its first archive snapshot.
• A recycled URL: two articles, one address — why "archived before the claimed date" has two possible explanations, and how one click tells them apart.
• The footer that told the truth — metadata says 2024, the page's own footer says 2006, and the footer wins.
• Dating a page that claims nothing: HTML 4.01 — no metadata, a 403 for every robot, and an honest upper bound that ran eight months late.
• The first website, and the limits of archives — every automated method arrives years late on the one page whose age everyone knows.
• The page that carries its own birth certificate — dating a Wikipedia article from the one source nothing else has: the wiki’s own revision history.
• Two true dates: the Bitcoin whitepaper — the file says March 2009, the bibliographies say October 2008, and both are right: what a PDF’s timestamp actually dates.
• The page older than its own history — a wiki’s revision history says September 2003; the archive photographed the page alive in July. When the birth certificate is wrong.
• The tweet that outlived its deletion — the covfefe tweet was deleted within six hours in 2017; its URL still dates it to the millisecond, and the archive photographed it one second in.
• The platform that borrowed a clock — no research existed on Threads post-URL timestamps, so an archived page’s own embedded clock verified the decode: ten posts, ten matches, seconds apart.
• One photograph, four clocks — the Situation Room photograph carries a 2011 shutter time, a 2011 posting, a 2018 re-save, and machine metadata claiming 2025; which clock answers which question.

Short, honest guides to the dating questions that bring people here — each one opens with the tool already running on a page that demonstrates the answer:

• How to find out when a web page was published — where real answers come from, and what to do when nothing answers.
• How to cite a website with no date — when (n.d.) is the right answer in APA 7, MLA 9, Chicago and Wikipedia, and how to check the date isn't findable first.
• How to find out when a photo was taken — reading a photo's own EXIF bytes from a URL, and why capture and posting are different dates.
• How to date a deleted tweet or post — the creation timestamp hiding in every post ID on seven platforms — deletion can't erase it.
• How to find out when a PDF was created — the file's embedded clock, and why it dates the export, not the publication.

The reason most people need a publication date is to cite the page — so after every check, the Cite this page box builds ready-to-copy citations in APA 7, MLA 9, Chicago, and the Wikipedia {{cite web}} template, using the estimated date plus the title, site name and author read from the page's own metadata. The honesty rules carry over into the citation: when the evidence only supports an upper bound ("online by"), the citation says n.d. — no date — instead of pretending the archive snapshot is a publish date, and a low-confidence date carries a visible warning suggesting you verify it or cite n.d. For a reposted article, the citation uses the original publication date the page itself states, which is the date a citation wants.

Honest limits: automated extraction reads what the page declares, and pages misdeclare — a site name can land in the author field, and name-order inversion ("Last, First") assumes Western name order, which is wrong for many names. The note above the citations says exactly what was and wasn't found; check the fields before you paste one into a bibliography.

The people who need publication dates rarely need just one: a bibliography, a fact-check, a literature review, a link dump from a colleague — it's always a list. The check a whole list link (next to the examples above) opens list mode: paste up to 20 URLs, one per line — blank lines, # comments, bullets and Markdown links are handled — and each URL gets exactly the same full check as a single one, two at a time. The honest cost: every URL means fetching the page, its feed and sitemap, the archive and the domain records, so a long list takes a few minutes; the table fills in as results arrive, with each row's estimated date, confidence badge and warning flags, and every row opens into its full evidence in a new tab.

When the list finishes, the Bibliography line expands into a ready-to-copy reference list of every dated result — APA 7, MLA 9, Chicago, or Wikipedia {{cite web}} — sorted alphabetically as reference lists want (the Wikipedia format keeps your input order, since those are inline templates). The honesty rules apply per entry: a source whose evidence only supports an upper bound is cited as n.d. rather than given a fake date, and reposted articles are cited by the original date they state. There's also a CSV download with every column — URL, estimated date, confidence, reason, flags, title, authors, site — for spreadsheets and further sorting. As everywhere on this site, nothing you paste is stored.

After a check, Copy link to this result gives you a link that re-runs the same check for whoever opens it — useful for showing a colleague that a source date-bumps, or citing your evidence. The checked URL travels in the link's # fragment, which browsers keep to themselves: it never appears in this site's server logs.

Copy link with preview card is the variant for chat apps and social posts: its link carries a signed summary of the result in the link itself, so the preview that Slack, Discord or Bluesky unfurls names the estimated date and confidence instead of a generic card. Two honest trade-offs: the checked URL is part of that link (so whatever fetches the preview sees it — still nothing is stored or logged here), and the preview is a snapshot from when the link was made — opening the link re-runs the check live, which is always the real answer. The summary is cryptographically signed at check time, so a hand-edited link can't put a date this tool never computed into a preview under PageDate's name; a tampered link still opens, but its preview makes no claims.

The URL you check is fetched once by this site's server (browsers can't read other sites directly — CORS forbids it), along with the site's robots.txt and sitemap, and its feed if the page declares one, and by the Wayback Machine API; for pages on Wikimedia-hosted wikis, the wiki's public history API is asked for that page's first revision; the page's domain name (never the full URL) is also looked up in the public RDAP registration database. The URLs you check are not stored, logged, or shared; regular share links carry the URL in the # fragment, which never reaches the server. Preview-card share links are the documented exception: the checked URL and a signed result summary travel in the link itself so chat apps can show the result — the server renders that preview from the link alone, and still stores and logs nothing. This site keeps only an anonymous visit count. No signup, no cookies for tracking.

The Your recent checks list is stored only in this browser's localStorage — the server never sees it, it is never transmitted anywhere, and the × and Forget-all buttons wipe it. It exists so a re-check can be compared against what the page said last time: if the estimate moved between your checks, PageDate says so — a quietly changed date is exactly what this tool is for. Entries expire after 180 days, and the case-file demo pages record nothing.