Browser timestamp formats explained
2026-05-19 · 2 min
The single most common browser forensics mistake is an epoch slip. Render
a Chromium last_visit_time with the Unix epoch and every visit lands in
the 1600s. Three formats cover almost everything you will see in the wild.
Chromium (Chrome, Edge, Brave, Opera)
Microseconds since 1601-01-01 00:00:00 UTC, the WebKit/FILETIME epoch.
Used by urls.last_visit_time, visits.visit_time, cookies.creation_utc,
downloads.start_time, and most of the other timestamp columns in
History, Cookies, and Login Data.
unix_ms = chromium_value / 1000 - 11644473600000
The gotcha: autofill.date_created and autofill.date_last_used are plain
Unix seconds. Same database, different column convention. Verify by sanity-
checking a known event before bulk-converting.
Firefox (PRTime)
Microseconds since 1970-01-01 00:00:00 UTC. Used in moz_places.last_visit_date,
moz_historyvisits.visit_date, and moz_bookmarks.dateAdded.
unix_ms = firefox_value / 1000
Exception: moz_cookies.expiry is Unix seconds, and moz_cookies.creationTime
/ lastAccessed are PRTime microseconds. Mixed conventions in a single table.
Safari (Mac absolute time)
Seconds (often fractional) since 2001-01-01 00:00:00 UTC, also called
Cocoa or CFAbsoluteTime. Used in History.db and the .plist sidecars.
unix_ms = (safari_value + 978307200) * 1000
Timezone discipline
None of these formats carry a timezone — they are all UTC. If you render them in the analyst's local time, two people in different timezones will disagree about when something happened. Keep timelines in UTC, label explicitly when you render locally, and confirm by aligning one known event (a VPN connect, a corporate SSO record from EVTX) before trusting the rest.