Chrome / WebKit Timestamp Converter
Paste a 17-digit value from a Chrome database — microseconds since January 1, 1601 — and instantly see the date it represents, in UTC and your own time zone.
The 17-digit number in your browser history
If you have ever opened one of the files a web browser keeps its history in, you will have met a column full of enormous numbers where you expected dates. Something like 13350000000000000. It is a date — just written as a running count rather than a calendar entry.
The count is in microseconds (millionths of a second), and it starts on 1 January 1601. Chrome inherited that starting point from Windows, which chose it because it lines up neatly with a 400-year cycle of the Gregorian calendar. Four centuries of microseconds is a very large number, which is why every real date comes out 17 digits long. Subtract the gap between 1601 and 1970 and you have an ordinary Unix timestamp.
This format is used by every Chromium-based browser — Chrome, Microsoft Edge, Brave, Opera, Vivaldi — so anything below applies to all of them. It is sometimes called a “WebKit timestamp” after the rendering engine Chromium originally forked from, which is a genuinely misleading name — see below.
Despite the name, Safari does not use this
“WebKit timestamp” is a historical misnomer. WebKit is Apple's engine, and Safari is the browser built on it — but Safari stores time in a completely different format, and modern WebKit itself uses the ordinary Unix epoch internally. The 1601-based format described on this page is a Chromium convention that outlived the name.
If you are reading Safari's History.db, the history_visits.visit_time column is Apple's Core Data absolute time: a decimal count of seconds since 1 January 2001, not microseconds since 1601. The numbers look nothing alike — Core Data values are around 10 digits with a fractional part — so use the Cocoa / Apple timestamp converter for those. The same applies to Safari on iOS and to most Core Data-backed apps.
Where these timestamps live
Chrome stores its data in SQLite databases inside the profile folder. These are the columns that hold a WebKit value:
| File | Column | What it records |
|---|---|---|
| History | urls.last_visit_time | Most recent visit to that URL |
| History | visits.visit_time | One row per individual page visit |
| History | downloads.start_time | When a download began |
| History | downloads.end_time | When it finished (0 if interrupted) |
| Network/Cookies | cookies.creation_utc | When the cookie was first set |
| Network/Cookies | cookies.expires_utc | Expiry — 0 means a session cookie |
| Network/Cookies | cookies.last_access_utc | Last time it was sent with a request |
| Login Data | logins.date_created | When the credential was saved |
| Login Data | logins.date_last_used | Last autofill of that credential |
| Web Data | autofill.date_last_used | Last use of a saved form value |
| Favicons | favicon_bitmaps.last_updated | When the icon was last fetched |
| Bookmarks (JSON) | date_added / date_last_used | Stored as a quoted string, not a number |
Always work on a copy. Chrome holds a lock on the live profile, and opening the database in place can modify the very file you are examining.
Got several values to line up at once — a browser visit against a server log, say? Compare Timestamps recognises Chrome/WebKit values alongside Unix epochs and Windows FILETIMEs, labels each row with the format it detected, and shows the gaps between them.
The mistake that costs you 4,000 years
Windows FILETIME values start from the same 1601 date, so the two formats look almost identical in a spreadsheet. The difference is the tick: FILETIME counts 100-nanosecond intervals, WebKit counts microseconds. A FILETIME is therefore ten times larger — 18 digits instead of 17 — and reading one as a WebKit value throws the answer roughly four thousand years into the future.
It is an easy mistake to make when a case involves both browser artefacts and Windows event logs, and nothing in the number itself warns you. The converter above checks whether its own answer is even possible for a browser to have written, and if it is not, tells you which format the digits more plausibly belong to.
Frequently asked questions
What is a Chrome/WebKit timestamp?
It is the way Chromium browsers record a moment in time: the number of microseconds that have passed since 1 January 1601. Because that starting point is so far in the past, any date from the last few decades lands on a 17-digit number such as 13350000000000000. You will run into one if you ever open the files Chrome keeps its history, cookies, or saved logins in.
Why does Chrome count from the year 1601?
It inherited the starting point from Windows. Microsoft picked 1601 because it is the beginning of the first 400-year cycle of the Gregorian calendar that includes the whole span computers were expected to care about, and Chromium reused the same reference point for portability across platforms. The choice is arbitrary — it just has to be consistent.
How do I convert a WebKit timestamp in SQLite?
Divide by 1,000,000 to get seconds, subtract 11,644,473,600 to shift from the 1601 epoch to the Unix epoch, then let SQLite format it: datetime(last_visit_time / 1000000 - 11644473600, 'unixepoch'). The generator on this page writes that query for you, along with Python, PowerShell, Node.js, Go and C# equivalents.
What does a value of 0 mean?
Zero is a sentinel meaning 'no value', not the year 1601. In the Cookies database an expires_utc of 0 marks a session cookie that is discarded when the browser closes. In History and Login Data it usually means the event was never recorded or has been cleared. Most converters silently print 1601-01-01 for this, which is misleading — this one says what it actually means.
Is a WebKit timestamp the same as a Windows FILETIME?
They share the 1601 starting point but tick at different rates: FILETIME counts 100-nanosecond intervals, WebKit counts whole microseconds, so a FILETIME is 10× larger and is typically 18 digits rather than 17. Mixing them up produces a date that is off by roughly 4,000 years. If you paste a value that decodes to something implausible, this converter tells you which other format it is more likely to be.
Where are Chrome's timestamp databases stored?
Inside the profile directory: %LOCALAPPDATA%\Google\Chrome\User Data\Default on Windows, ~/Library/Application Support/Google/Chrome/Default on macOS, and ~/.config/google-chrome/Default on Linux. The relevant files are History, Network/Cookies, Login Data, and Web Data — all SQLite databases, plus Bookmarks which is JSON.
Does this work for Edge, Brave, Opera and Vivaldi?
Yes. They are all built on Chromium and use the identical timestamp format and database schema — only the profile directory differs. The same conversion and the same queries apply unchanged.
Does Safari use WebKit timestamps?
No, despite the name. Safari stores time as Apple Core Data absolute time — a decimal count of seconds since 1 January 2001 — in the history_visits.visit_time column of History.db, and modern WebKit uses the Unix epoch internally. The 1601-based format is a Chromium convention that kept the WebKit name. For Safari values, use the Cocoa / Apple timestamp converter instead.
Are these timestamps UTC or local time?
The stored value is always UTC — it is an absolute count from a fixed instant, with no time zone attached. The local time shown above is your own machine's interpretation of that instant. For forensic work, report the UTC value or state the time zone explicitly, since the same number renders as a different wall-clock time on a different machine.