HesapHanem

Windows FILETIME Converter

Enter a FILETIME tick value or a date to convert.

How it is calculated

A Windows FILETIME counts 100-nanosecond ticks since 1601-01-01 00:00:00 UTC. To read a tick count, the tool uses unix seconds = ticks ÷ 10,000,000 − 11,644,473,600, where the constant is the number of seconds between 1601 and 1970, and formats the result as UTC. In the other direction, ticks = (unix seconds + 11,644,473,600) × 10,000,000, where your text is read as a date and time in UTC unless it carries its own offset such as +02:00. The ticks to date direction rounds to the nearest whole second, so the last seven digits of precision are dropped, and negative tick values give no result. Any date text the server can parse is accepted, and an unreadable one gives nothing.

Worked example

An Active Directory attribute shows the tick count 133500000000000000. Divide by 10,000,000 to get 13,350,000,000 seconds since 1601. Subtract the 1601 to 1970 offset of 11,644,473,600: 13,350,000,000 − 11,644,473,600 = 1,705,526,400 seconds since 1970 (the Unix time). That corresponds to 2024-01-17 21:20:00 UTC. Going back the other way with that date gives exactly 133,500,000,000,000,000 ticks.

Try this example →

Common mistakes

  • Treating the number as Unix seconds or milliseconds. A FILETIME is about 18 digits long; a 10-digit value is Unix time and 13 digits is Unix milliseconds, and neither belongs in this field.
  • Reading the output as local time. The result is always UTC, so convert it to your time zone yourself before comparing with a local clock.
  • Typing a date without a time zone and expecting local time. Text with no offset is read as UTC; add +02:00 or similar if the date is local, and the tool shifts it correctly.
  • Pasting a hexadecimal value, such as the high and low parts shown in a tool. The tick value must be a decimal number; a hex value or one with spaces and commas is not read.
  • Expecting sub-second detail. The date result is rounded to the second, so values that differ by a few million ticks can show the same time.

About this calculator

Windows represents timestamps internally as FILETIME values — a 64-bit count of 100-nanosecond intervals ("ticks") elapsed since January 1, 1601, 00:00:00 UTC, a reference date chosen because it starts the first full 400-year Gregorian calendar cycle before the epoch. This format shows up throughout the Windows ecosystem: NTFS file creation/modification timestamps, Windows Event Log entries, and Active Directory attributes like lastLogonTimestamp and pwdLastSet are all stored this way.

Converting to a human-readable date (or to the more familiar Unix epoch of January 1, 1970) requires subtracting the offset between the two epochs — 11,644,473,600 seconds, or 116,444,736,000,000,000 in 100-nanosecond ticks — then dividing by 10,000,000 to get Unix seconds. Digital forensics investigators and incident responders decode FILETIME values constantly when reading raw Windows artifacts that don't display a formatted date on their own.

Was this helpful?

You can pick up to 3 reactions.

Comments (1)

  • Editorial team

    Two Active Directory values behave oddly here. An accountExpires of 0 or 9223372036854775807 means the account never expires, but the tool will still print a literal date, 1601 for the first and the year 30828 for the second. Read those as markers, not dates. Which attributes do you decode most often: lastLogon, pwdLastSet or something else?

Popular calculators

Loan Calculator

Monthly payment, total interest and full amortization schedule.

Percentage Calculator

Percent change, percent of, and ratio calculations.

Discount Calculator

Calculate final price, savings, and discount amount.

BMI Calculator

Body mass index from height and weight (metric or imperial).

Age Calculator

Compute your exact age in years, months and days from a birth date.

Compound Interest Calculator

Calculate the final amount and interest earned with compounding.

All Calculators