Convert and analyze timestamps from various formats (Unix, Windows FILETIME, NTFS, HFS+) for digital forensics.
Paste a timestamp in any of the formats investigators actually meet - Unix epoch seconds, milliseconds, or microseconds; Windows FILETIME (100-nanosecond units since 1601); or the classic Macintosh epoch (seconds since 1904) used by HFS+ - and the tool returns the UTC date and time. Work in reverse too: enter a date, get the number for each format. The arithmetic is a fixed offset, so the tool's real job is identifying the unit and epoch. Two things surprise people: NTFS stores FILETIME values unchanged, so the two are the same number, and HFS+ catalog times are stored as local wall-clock time, not UTC.
A concrete input and expected output from the current implementation.
Input
1700000000
Expected output
Unix (seconds): 2023-11-14 22:13:20 UTC Milliseconds: 1700000000000 Windows FILETIME / NTFS: 133444736000000000 HFS+ (seconds since 1904): 3782844800
1700000000 is 19,675 days and 80,000 seconds after 1970-01-01; 19,675 days ends on 2023-11-14 and 80,000 seconds is 22:13:20, so the instant is 2023-11-14 22:13:20 UTC. The FILETIME value adds the 11,644,473,600-second gap between the 1601 and 1970 epochs and scales to 100-nanosecond ticks; the HFS+ value adds the 2,082,844,800-second gap between 1904 and 1970.
The tool infers the unit from the magnitude of the number: a date in the 2020s sits near 1.7 billion as seconds, 1.7 trillion as milliseconds, 1.7 quadrillion as microseconds, and about 133 quadrillion as FILETIME. It then applies the fixed epoch offsets: FILETIME counts from 1601-01-01, which is 11,644,473,600 seconds before the 1970 Unix epoch, and the Macintosh epoch (1904-01-01) is 2,082,844,800 seconds before it. All arithmetic happens locally in the page.
Enter a date and the tool returns the value in each format, which is what you want when building search predicates for forensic tooling. FILETIME and NTFS produce identical numbers because NTFS stores its timestamps as FILETIME values. HFS+ is reported as raw seconds since 1904, and the tool also applies the timezone you select, because HFS+ catalog records hold local wall-clock values rather than UTC.
FILETIME counts 100-nanosecond ticks from 1601-01-01, and the 1970 epoch is 11,644,473,600 seconds - about 369 years - later. A date near late 2023 therefore sits at roughly 133 quadrillion ticks. If a value you assumed was FILETIME is closer to 1.7 quadrillion, it is actually microseconds.
Unix, FILETIME, and NTFS values are absolute instants, so they convert straight to UTC and the timezone selector only changes how the date is displayed. HFS+ is different: catalog times are local wall-clock readings, so the correct instant depends on the original machine's timezone and its DST rules, which cannot be recovered from the number alone.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.