Unix Timestamp Converter

How to convert a Unix timestamp

Enter a numeric epoch value or a complete ISO date-time with a timezone. Choose an explicit unit whenever you know it. Auto mode uses magnitude to distinguish common seconds and milliseconds values, then displays the exact detected interpretation so the conversion is reviewable.

1. Choose Auto, Seconds, Milliseconds or ISO. ISO mode requires a full date, time and Z or numeric offset.
2. Enter the value without thousands separators or unit suffixes. Decimal seconds are accepted; milliseconds are interpreted directly.
3. Convert and compare the UTC ISO value, browser-local display, epoch seconds and epoch milliseconds.
4. Confirm the shown local timezone and detected unit before using the result in logs, databases or scheduled jobs.

Examples and expected behavior

Seconds, milliseconds and auto-detection

A Unix timestamp counts elapsed time from 1970-01-01T00:00:00Z. Many systems store whole or fractional seconds, while JavaScript Date and numerous web APIs use milliseconds. Confusing the units shifts the interpreted date by a factor of one thousand. Explicit Seconds or Milliseconds mode is therefore the safest choice when the source format is documented.

Auto mode uses a practical magnitude threshold: absolute numeric values at or above 100,000,000,000 are treated as milliseconds, and smaller values as seconds. This works for ordinary modern dates but cannot infer intent perfectly for very distant dates or unusual domain values. The result always shows the detected mode, so review it instead of assuming digit count alone is authoritative.

• Ten-digit modern epochs are usually seconds.
• Thirteen-digit modern epochs are usually milliseconds.
• Negative values are supported within the JavaScript Date range.

ISO input and strict calendar validation

ISO mode accepts a complete date-time with seconds and either Z or a numeric timezone offset such as +08:00. Requiring a timezone avoids the ambiguous behavior of timezone-less strings, which different environments may interpret as local time. Fractional seconds with one to three digits are accepted and normalized to milliseconds.

The converter validates the calendar fields instead of relying only on Date.parse. Dates such as 2024-02-30, hour 25 or an invalid offset are rejected rather than silently rolled into another instant. Leap years and month lengths are checked through a round-trip comparison. This strictness makes errors visible before a timestamp is copied into a database or scheduler.

• Use Z for UTC.
• Use an explicit +HH:MM or -HH:MM offset for a known local offset.
• Timezone abbreviations such as EST or CST are not accepted because they are ambiguous.

UTC, local time and timezone display

The ISO result is always UTC and ends in Z. The local result is formatted with the browser’s current locale and IANA timezone, such as America/New_York or Asia/Shanghai. Daylight-saving rules come from the browser and operating system timezone database. Two users can therefore see different local clock times for the same epoch while the UTC instant remains identical.

A timezone offset describes one instant, while an IANA zone contains historical and future daylight-saving rules. This tool displays the current browser zone but does not let you simulate an arbitrary named zone. For scheduling across regions, store the instant in UTC and separately store the intended IANA zone when future wall-clock behavior matters.

• UTC is the stable comparison format for logs and APIs.
• Local formatting is for human interpretation, not a portable storage format.
• Check the displayed zone when using a remote desktop, virtual machine or travel laptop.

Range, precision and leap-second limits

JavaScript Date supports finite millisecond values roughly within plus or minus 8.64 quadrillion milliseconds from the epoch. Inputs outside that range are rejected. Numeric conversion uses JavaScript Number, so extremely large fractional values may lose precision before reaching the Date limit. Millisecond output may also be fractional when the input contains fractional milliseconds.

Unix time conventionally ignores leap seconds by mapping civil time onto a continuous count used by the platform. This page follows browser Date behavior and cannot represent 23:59:60. Systems with specialized astronomical or monotonic time requirements need domain-specific libraries. For application logs and web APIs, the displayed ISO, seconds and milliseconds values are the relevant interoperable forms.

• No thousands separators or words such as ms are accepted in the numeric field.
• NaN and Infinity are invalid.
• Leap seconds are not represented by JavaScript Date.

Common uses and debugging workflow

Timestamp conversion is useful when reading database rows, browser console logs, JWT claims, analytics events, webhook payloads and scheduler records. It helps determine whether a value is seconds or milliseconds, whether an event occurred in the expected timezone and whether a client sent a stale or future timestamp.

When debugging, first identify the documented unit, then convert in explicit mode. Compare the UTC result across systems before comparing local displays. If an event appears several hours off, investigate timezone handling; if it appears decades or millennia off, investigate seconds-versus-milliseconds confusion. Preserve the original raw value in incident notes so the conversion can be reproduced.

• Inspect iat, exp or nbf values from decoded token payloads.
• Translate log epochs into a readable incident timeline.
• Verify database migrations between seconds and milliseconds columns.
• Check webhook signatures that include timestamp headers without altering the raw signed text.

Errors and boundary decisions

Empty input, malformed numbers, invalid ISO syntax, impossible calendar dates and out-of-range values are reported separately. Numeric mode does not accept embedded spaces, commas or suffixes. ISO mode does not accept a date-only value or a timezone-less local date-time. These constraints prevent environment-dependent parsing.

The page converts one instant at a time and does not parse duration strings, cron expressions, relative phrases such as tomorrow, Excel serial dates or GPS time. It also does not calculate business days. Use a timezone-aware scheduling library when recurrence and daylight-saving transitions are part of the problem. This converter is intentionally focused on deterministic epoch and ISO interchange.

• A valid timestamp does not prove an event is trustworthy.
• Auto-detection is a convenience, not a source-of-truth schema.
• Keep the original unit documented in database and API field names.

How this differs from UUID and hash tools

A timestamp represents when something happened and is often predictable. It is not a unique identifier and should not be used as a secret or random token. A UUID v4 provides randomized identifier space, while a hash produces a deterministic digest of data. Combining a timestamp with weak randomness does not create a secure identifier.

Use timestamps for ordering and temporal queries, UUIDs for identifiers that should not collide, and HMACs for authenticating a timestamp together with a message. When a protocol signs a timestamp, convert a copy for human review but preserve the exact original string for signature verification because formatting or unit conversion changes the authenticated bytes.