Unix Timestamp Converter

This converter moves between Unix epoch timestamps and human-readable dates in both directions. It auto-detects whether a pasted timestamp is in seconds or milliseconds, and shows the result in UTC, ISO 8601 and your local time zone, plus a relative ("3 hours ago") description.

Log correlation across firewalls, EDR agents, cloud audit trails and SIEMs frequently means reconciling different timestamp formats and time zones. A firewall might log in local time, a cloud provider in UTC epoch milliseconds, and an EDR agent in epoch seconds -- being able to quickly normalize all three to a common reference is essential for building an accurate incident timeline.

Epoch time counts seconds (or milliseconds) since 00:00:00 UTC on January 1, 1970. The tool multiplies or divides by 1000 as needed and hands the result to the JavaScript Date object, which natively renders UTC, ISO 8601 and locale-aware local time strings. Auto-detection uses magnitude: a 10-digit number is almost certainly seconds, while a 13-digit number is almost certainly milliseconds.

1. 1To read a timestamp: paste it into the Unix timestamp field; the tool auto-detects seconds vs milliseconds, or you can force one manually.
2. 2Review the UTC, ISO 8601, local and relative time outputs.
3. 3To convert a date: pick a date/time in the local picker and read off the equivalent Unix seconds and milliseconds.
4. 4Use Now on either side to grab the current moment instantly.

1717257127 (10 digits) is auto-detected as seconds and converts to a UTC date in 2024. 1717257127000 (13 digits) is the same moment in milliseconds.

Converting a suspicious login time reported as "2024-06-01 14:32 local" to UTC lets you match it against a cloud provider's audit log, which is almost always recorded in UTC.

• Mixing up seconds and milliseconds -- a value that looks like 'the year 46000' is usually seconds mistakenly treated as milliseconds, or vice versa.
• Comparing timestamps without normalizing time zones first, leading to off-by-hours errors in an incident timeline.
• Forgetting that many logging systems record in UTC even when displaying local time in a UI.
• Assuming a negative or extremely large timestamp is valid input rather than a parsing bug upstream.

Accurate time correlation is critical during incident response -- an attacker's dwell time, lateral movement path, and root cause can all be misread if timestamps aren't normalized consistently. Always record which time zone and unit a source system uses before combining timestamps from multiple tools into a single timeline.