Gera Tools

Windows FILETIME Converter

Convert Windows FILETIME 64-bit values to readable dates

Convert a Windows FILETIME value to a UTC date and back. FILETIME counts 100-nanosecond intervals since 1601-01-01, and the tool accepts decimal or hex input using exact BigInt arithmetic and shows the matching Unix timestamp. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is a Windows FILETIME?

FILETIME is a 64-bit value that counts the number of 100-nanosecond intervals since midnight on 1 January 1601 in UTC. Windows uses it for file timestamps and many system APIs.

What a FILETIME value is

Windows records timestamps as a FILETIME: a 64-bit count of 100-nanosecond intervals since the start of 1 January 1601, in UTC. You will see these values in the registry, in file metadata, in event logs, and in forensic tooling, usually as a large decimal or a hex blob. This tool converts a FILETIME to a readable UTC date and back, and accepts either decimal or hexadecimal input.

How it works

The conversion hinges on the offset between the FILETIME epoch and the Unix epoch. Midnight on 1 January 1970 sits exactly 116,444,736,000,000,000 intervals (100-nanosecond ticks) after the FILETIME origin. Subtracting that constant maps the FILETIME onto Unix-based time: dividing the remainder by 10,000 gives milliseconds for a JavaScript Date, and dividing by 10,000,000 gives whole Unix seconds. The reverse direction adds the offset back after scaling the date’s milliseconds.

FILETIME → date:
  unix_ms = (FILETIME - 116444736000000000) / 10000
  date    = new Date(unix_ms)

date → FILETIME:
  FILETIME = (unix_ms * 10000) + 116444736000000000

All arithmetic uses BigInt so the high-order digits of the 64-bit value are never lost to floating-point rounding — standard JavaScript numbers lose precision above 2^53, which is smaller than a typical FILETIME value.

Worked conversion examples

133100064000000000   (decimal)  →  2022-10-12T00:00:00Z  (Unix: 1665532800)
0x01D8DCE000000000  (hex)       →  same result (same value, hex notation)
2022-12-01T00:00:00Z            →  133143264000000000 decimal

For the hex example, the tool strips the 0x prefix and parses the rest as base-16 before applying the epoch offset. The decimal and hex forms represent identical bit patterns.

Where you encounter FILETIME in practice

Digital forensics and incident response

FILETIME timestamps appear in:

  • NTFS $MFT file created, modified, accessed, and changed ($STANDARD_INFORMATION and $FILE_NAME attributes)
  • Windows Registry key LastWriteTime values
  • Event logs (<EventData> time attributes in .evtx files)
  • Prefetch file headers (recording when an executable last ran)
  • LNK file (shortcut) target and link timestamps
  • Browser history databases for Edge/IE

In all these contexts, the raw FILETIME is stored as a 64-bit little-endian integer. Hex dumps from tools like Volatility, RegRipper, or FTK Imager display them as sequences like 00 60 E0 AC D8 01 D8 01, which must be read in reversed-byte order as 0x01D8D801ACE06000 before conversion.

Windows APIs

The FILETIME structure (a pair of 32-bit DWORD values, high and low) is used throughout the Win32 API: GetSystemTimeAsFileTime, CompareFileTime, CreateFile timestamps. When logging or correlating these with Unix-based systems (Linux logs, cloud events), the epoch difference must be applied.

Important: FILETIME is always UTC

FILETIME stores UTC time with no timezone offset embedded. Windows displays local times in File Explorer and Event Viewer by applying your system’s current timezone offset — the underlying FILETIME is not changed. When converting, interpret the result as UTC; apply a timezone offset separately only if you need to display local time.

If you have a local Windows timestamp from a screenshot or log that appears to be in a timezone other than UTC, convert it to UTC before entering it for the reverse conversion.