WebKit / Chrome Timestamp

WebKit timestamps count microseconds since January 1, 1601 UTC. Chrome, Edge, Opera, and other Chromium-based browsers use this format throughout their internal databases, so anyone reading a browser history file, a cookie store, or a download log runs into these seventeen-digit numbers. Paste one here to get a readable date, or pick a calendar date to produce the WebKit value for that day.

Why 1601

The epoch is inherited from Windows, whose FILETIME structure counts from the same instant. That date was chosen because it begins a four-hundred-year Gregorian leap cycle, which made the calendar arithmetic tidy for the system designers. WebKit adopted the same starting point but changed the resolution: FILETIME counts hundred-nanosecond intervals, while WebKit counts whole microseconds. The two formats therefore differ by a factor of ten even though they share an epoch, and confusing them shifts a result by a large margin rather than a subtle one.

The conversion

Divide the WebKit value by one million to get seconds since 1601, then subtract 11,644,473,600 — the number of seconds between the 1601 epoch and the Unix epoch of 1970. What remains is an ordinary Unix timestamp. Working in the other direction, add that same constant and multiply by one million.

These numbers are large enough that precision matters. A WebKit timestamp for a recent date has seventeen digits, comfortably beyond the range where double-precision floating point represents every integer exactly. Spreadsheet formulas and quick scripts in languages without integer types will round the last digits, which usually shows up as a time that is off by a fraction of a second — harmless for casual reading, but wrong if you are correlating events at millisecond resolution.

Where these values appear

The Chromium history database stores visit times, typed URL times, and download start and end times in this format. The cookie store records creation, expiry, and last-access times the same way. Cache metadata, autofill entries, login records, and the timestamps behind bookmark folders all use it. Because the browser profile is a set of SQLite databases, these numbers are what you see when you query them directly rather than through the browser interface.

The format also turns up in exported forensic reports, which frequently pass the raw integers through unchanged. If a tool hands you a column of seventeen-digit numbers alongside URLs, WebKit time is the safe first guess.

Resolution versus accuracy

Microsecond resolution does not mean microsecond accuracy. The stored value comes from the system clock at the moment the browser wrote the record, and that clock is subject to the usual imperfections: network time synchronization steps, drift between syncs, and manual changes by the user. Two events a few hundred microseconds apart cannot be reliably ordered by their timestamps alone, and a machine whose clock was adjusted mid-session can produce records that appear out of sequence.

For most work this is irrelevant, because the interesting intervals are seconds or minutes rather than fractions of a millisecond. It becomes important when you are arguing that one event caused another, or reconstructing a precise sequence across several machines. In those cases treat the timestamp as strong evidence of approximate time and weak evidence of exact ordering.

Reading a value at a glance

Length is the quickest signal. Seventeen digits indicates a modern date; thirteen digits is far more likely to be a Unix millisecond timestamp, and ten digits a Unix seconds value. A WebKit timestamp of zero means the field was never set rather than a date in 1601, and browsers use zero this way for sessions that have not expired or downloads that never finished. Treat zero as null, not as a real instant.

Negative values are theoretically representable but do not occur in practice, so a negative number in a browser database usually means the column was misread or the file is damaged.

Time zones and interpretation

WebKit timestamps are always UTC. The browser converts to local time only when displaying history to the user, so a value pulled from the database has no zone attached and needs no adjustment before comparison. When building a timeline that mixes browser records with file system timestamps or server logs, normalize everything to UTC first and convert once at the end. The time zone converter handles the final step, and the ISO 8601 converter produces a string safe to paste into a report.

Practical checks

When you convert a batch of values, spot-check one against a known event. If a history entry corresponds to a visit you can date independently, converting it confirms both the format and your arithmetic in a single step. A result that lands in 1601 means you forgot the epoch offset; a result that lands roughly in 1970 means you subtracted the offset from a value that was already Unix time.

Results off by exactly a factor of ten point to FILETIME rather than WebKit. Use the FILETIME converter in that case, which applies the hundred-nanosecond scale.

Related converters

Apple software counts from a different epoch entirely — see the Cocoa timestamp converter for seconds since 2001. Active Directory and LDAP share the 1601 epoch with FILETIME and are covered by the LDAP timestamp converter. Ordinary epoch seconds belong on the Unix timestamp converter, with a batch mode for long lists and a hex variant for values stored in hexadecimal. The full set is on the converters hub.

A note on browser versions

The format has been stable across Chromium releases for many years, and the same epoch and resolution apply to Chrome, Edge, Brave, Vivaldi, and other browsers built on the same engine. Individual database schemas change between versions — column names and table layouts move around — but the timestamp encoding itself has not. If a value fails to convert sensibly, the problem is far more likely to be the column you read than the format itself.