Chrome & WebKit Timestamp Converter
Decode a browser timestamp
Paste a raw value from a Chrome, Safari or Firefox database. Every reading is shown, because the same digits are a valid timestamp in more than one format.
Date to a stored value
For writing a WHERE clause against one of these databases.
Which column is which
The tables and columns these values come out of, so you can work backwards from what you are looking at.
| Database | Column | Format |
|---|---|---|
| Chrome History | urls.last_visit_time | Chrome / WebKit |
| Chrome History | visits.visit_time | Chrome / WebKit |
| Chrome History | downloads.start_time | Chrome / WebKit |
| Chrome Cookies | cookies.creation_utc | Chrome / WebKit |
| Chrome Cookies | cookies.expires_utc | Chrome / WebKit |
| Chrome Cookies | cookies.last_access_utc | Chrome / WebKit |
| Chrome Login Data | logins.date_created | Chrome / WebKit |
| Safari History | history_visits.visit_time | Cocoa / Core Data / NSDate |
| Firefox places | moz_places.last_visit_date | Unix seconds |
Raw values out of browser databases, decoded as every format they could be.
Chrome and WebKit: microseconds since 1601
Chrome, Edge and Chromium store times as a 64-bit count of microseconds since 1 January 1601 at 00:00 UTC. A present-day value is 17 digits, so 13350000000000000 is 17 January 2024. Divide by a million for seconds, then subtract 11,644,473,600 to reach the Unix epoch.
It shares the 1601 epoch with Windows FILETIME, which is where the confusion usually starts. FILETIME counts 100-nanosecond intervals, so for the same instant it is exactly ten times larger and 18 digits long. If a value converts to a date roughly ten times too far in the future, you have used the wrong one of the two. Our LDAP timestamp converter handles the FILETIME side.
Why the same digits decode three ways
A ten-digit number is a valid Cocoa timestamp, a valid HFS+ timestamp and a valid Unix timestamp all at once, and the three land decades apart. 725843000 is 2024 read as Cocoa and 1992 read as Unix. Both are ordinary-looking dates, so nothing about the result tells you which is right.
That is why this page shows every reading rather than picking one. Only the person holding the file knows which database the value came out of, and a confident wrong answer in a timeline is worse than three labelled candidates.
Cocoa, Core Data and NSDate
Apple frameworks count seconds from 1 January 2001 at 00:00 UTC, the reference date behind NSDate and Core Data. Today that is a number in the seven hundred millions, often with a fractional part because the value is a double rather than an integer. Safari history, plists and Core Data stores all use it. Read as Unix seconds by mistake it lands in the early nineties, which is the sort of wrong answer that survives review because it looks reasonable.
Zero is not 1601
A zero in one of these columns means the row has no value. expires_utc = 0 in Chrome Cookies is a session cookie that is never written to disk with an expiry, and a zero visit time in History means no visit was recorded. Rendering it as 1 January 1601 is arithmetically correct and tells you nothing about what you are looking at.
Browser timestamp FAQs
What is a Chrome or WebKit timestamp?
A 64-bit count of microseconds since 1 January 1601 at 00:00 UTC. Chrome, Edge, Chromium and older WebKit builds use it in their SQLite databases, so a present-day value is 17 digits. It shares the 1601 epoch with Windows FILETIME but counts microseconds rather than 100-nanosecond intervals, which makes it exactly ten times smaller for the same instant.
Which columns hold these values?
In Chrome History, urls.last_visit_time, visits.visit_time and downloads.start_time. In Chrome Cookies, cookies.creation_utc, expires_utc and last_access_utc. In Login Data, logins.date_created. Safari History uses history_visits.visit_time, which is a Cocoa timestamp instead. Firefox places.sqlite uses microseconds since the Unix epoch, so it is a different thing again.
What is a Cocoa, Core Data or NSDate timestamp?
Seconds since 1 January 2001 at 00:00 UTC, the reference date Apple frameworks use. Values are around 700 to 800 million today, and they are often stored as a float with a fractional part. Safari, Core Data stores and many plists use it. Read as a Unix timestamp by mistake it lands in the early 1990s, which is a plausible-looking wrong answer rather than an obvious one.
Why does this show several answers instead of one?
Because a ten-digit number is a valid Cocoa, HFS+ and Unix timestamp at the same time, and the three decode to dates decades apart. Only you know which database the value came from. Guessing one and presenting it as the answer is how a forensic timeline ends up wrong by thirty years, so every reading is shown and the plausible ones are ordered first.
What does a zero mean?
That the row has no value, not a date in 1601. In Chrome Cookies, expires_utc = 0 is a session cookie that is not persisted to disk. In History, a zero visit time means no visit was recorded. Converters that render zero as 1 January 1601 are technically right and practically misleading.
What is a Mac HFS+ timestamp?
Seconds since 1 January 1904, used for file creation and modification times on HFS+ volumes. Modern APFS uses nanoseconds since the Unix epoch instead, so a value from a current Mac is far more likely to be Unix or Cocoa.
Is anything I paste sent to a server?
No. The conversion runs entirely in your browser and the page works offline. These values come out of browser histories and forensic images, which is exactly the sort of thing that should not be pasted into a server you do not control.