Timestamp converter

Convert Unix (s, ms, µs, ns), Windows FILETIME and LDAP/AD, Chrome/WebKit, macOS/Cocoa, HFS+ and Excel timestamps to UTC and local time, or turn a date into every format.

Runs in your browser. Nothing you paste is uploaded, stored or logged.

Try:

How it works

Building an incident timeline means lining up events from very different sources: Linux logs in Unix seconds, Windows event and registry data in FILETIME, Active Directory attributes in LDAP time, browser history in WebKit time and macOS artefacts in Cocoa time. Each counts from a different start date in a different unit.

Paste any value and the converter tries every common format, keeps the ones that give a realistic date, and shows each in UTC, your local time and relative to now. Hexadecimal values and FILETIME written as two halves (01DC5521:2B8E3C00) work too. Paste a date instead and you get that moment in every format, ready to search logs with.

Questions

How do I convert an LDAP or Active Directory timestamp?
Attributes such as lastLogonTimestamp, pwdLastSet and accountExpires are Windows FILETIME values: 100-nanosecond intervals since 1 January 1601 UTC. Paste the 18-digit number and the converter shows it in UTC and your local time. In accountExpires, the values 0 and 9223372036854775807 mean the account never expires.
Why does one number show several possible dates?
Timestamps carry no label, and the same number can be valid in more than one format. The converter tries them all, keeps those that give a date between 1980 and 2100, and lists the one closest to today first. Where the value came from usually settles it: a Chrome history database uses WebKit time, Active Directory uses FILETIME, and most logs use Unix time.
How do I convert Chrome or Edge history timestamps?
Chromium browsers (Chrome, Edge, Brave) store visit times such as last_visit_time as microseconds since 1 January 1601 UTC, usually 17 digits. Paste the value and read the Chrome / WebKit row.
Is precision lost?
No. Large values are handled as exact integers rather than floating point, so a Windows FILETIME keeps its full 100-nanosecond precision and nanosecond Unix times keep all nine digits after the second.