⭐ Starlight Tools / LDAP / FILETIME Converter

LDAP / FILETIME Converter

Convert Windows FILETIME timestamps (100-ns since 1601-01-01 UTC) to human-readable dates — and back. Decimal & hex supported. Fully client-side.

Related Tools

UNIX Timestamp Converter · Time Since / Until · Date Calculator · AOE Calculator

Results always include UTC; this controls the extra local view.
AD “Never”: 0 or 9223372036854775807 (0x7FFFFFFFFFFFFFFF)

1) LDAP / FILETIME → Date

Counts 100-ns intervals since 1601-01-01T00:00:00Z

2) Date → LDAP / FILETIME

Interpreted in your current local time zone.
If a zone/offset is provided, it will be respected.

About LDAP / FILETIME

Windows FILETIME (often called “LDAP time” in the context of Active Directory) is a 64-bit integer that counts 100-nanosecond intervals since 1601-01-01T00:00:00Z. Many AD attributes (for example, lastLogonTimestamp, pwdLastSet, and accountExpires) use this format.

This converter translates between that integer representation and human-readable dates. Enter either a decimal 18-digit value or a hexadecimal value (with or without a 0x prefix). Results are shown in UTC and your chosen display time zone. For attributes like accountExpires, special values of 0 and 9223372036854775807 represent Never.

LDAP / FILETIME Converter: FAQs

What’s the relationship to UNIX epoch?

FILETIME uses a different epoch (1601-01-01 UTC) and unit (100 ns). The tool converts via precise arithmetic with BigInt and an exact epoch offset so it’s safe for large values.

Does DST affect LDAP/FILETIME values?

No. LDAP/FILETIME values encode an absolute moment in UTC. Only the display in your selected time zone changes with DST.

Can I copy numeric and hex outputs?

Yes. Click the copy chips beside each output to copy decimal, hexadecimal, and ISO-8601 UTC.

What is LDAP / Windows FILETIME?

Windows FILETIME (often called LDAP time, NT time, or NTTIME) is a 64-bit signed integer used by Windows and Active Directory to represent absolute moments in time. The value counts the number of 100-nanosecond intervals (a.k.a. “ticks”) that have elapsed since the Windows epoch: 1601-01-01T00:00:00Z (UTC). Many directory attributes use this format, including lastLogonTimestamp, pwdLastSet, accountExpires, badPasswordTime, and more.

Why does Windows/LDAP use FILETIME?

FILETIME provides a compact, monotonic, time zone–agnostic representation with sub-second precision (100 ns). Because the value is UTC-based, it avoids daylight saving time pitfalls and regional formatting inconsistencies. In LDAP/AD, these values are stored as 64-bit integers and can be transported or indexed efficiently across systems.

How conversion works (the math)

Compared to the UNIX epoch (1970-01-01T00:00:00Z), the Windows epoch starts earlier. The exact gap is 11,644,473,600,000 milliseconds (that is, 11644473600 seconds). Conversion is therefore a simple offset plus a unit change:

  • FILETIME → milliseconds since 1970: ms = (filetime / 10,000) − 11,644,473,600,000
  • Milliseconds since 1970 → FILETIME: filetime = (ms + 11,644,473,600,000) × 10,000

Our converter performs this arithmetic safely with BigInt, then renders human-readable results in UTC and your chosen time zone. Because the underlying value is UTC, DST never alters the stored number—only the display string changes.

Special “Never” values in Active Directory

Some AD attributes use sentinel values to mean no expiry or not set. The most common are:

  • 0 — often interpreted as Never (e.g., accountExpires).
  • 9,223,372,036,854,775,807 (0x7FFFFFFFFFFFFFFF) — the maximum 64-bit signed integer, also used to indicate Never.

The tool detects and labels these values automatically so you don’t mistake them for real dates.

Hex or decimal? Endianness? Precision?

FILETIME values are frequently shown as 18-digit decimals in LDAP tools and logs. Some APIs and forensic utilities present the same value in hexadecimal (with or without a 0x prefix). Both point to the same 64-bit number, and this page accepts either form. Internally, Windows APIs expose FILETIME as two 32-bit parts; when serialized in binary structures they are little-endian, but LDAP/AD queries typically surface them as regular big-number integers—no byte-swapping is needed when you paste a string here.

JavaScript’s Number type cannot precisely represent all 64-bit integers. To avoid rounding, this converter uses BigInt for the math and only converts to Date once the value is safely in milliseconds, preserving accuracy for very large timestamps.

Common pitfalls & tips

  • Local vs UTC: FILETIME is UTC. If a string lacks an offset, your browser may interpret it as local time when converting back.
  • DST & leap seconds: DST does not change the stored value. Windows/UNIX time generally ignores leap seconds.
  • Range: Extremely large FILETIME values may exceed the practical range of the JavaScript Date (≈ ±8.6e15 ms). The tool warns if a value is out of range.
  • Audit/forensics: When investigating lastLogon vs lastLogonTimestamp, remember replication behavior; the precise tick still converts the same way.

Tip: Need a quick mental check? Divide the FILETIME by 10,000 to get milliseconds since 1601, subtract 11,644,473,600,000, and compare the result to today’s epoch milliseconds. Or just paste it above and let the converter handle the details—privately, in your browser.