Unix Time Converter for Epoch Seconds and Milliseconds

Unix time counts elapsed seconds from the Unix epoch, 1970-01-01 00:00:00 UTC:

An epoch timestamp identifies an instant. It does not contain a time-zone name, locale, calendar display format, or daylight-saving abbreviation — those are applied when software renders the instant.

Enter the timestamp, select Seconds or Millis, then read GMT Date, compare Local Date when local context matters, and treat Relative Time as an approximate convenience value. Internally the tool multiplies seconds by 1,000 because JavaScript Date accepts milliseconds; the GMT output uses toUTCString() and the local output uses Date.toString(). For example, epoch 0 represents the same instant everywhere:

GMT: Thu, 01 Jan 1970 00:00:00 GMT

Choose Millis when the value already counts thousandths of a second; the tool passes the integer directly to the date constructor. Using the wrong unit produces a dramatically different result: if 1784370916000 milliseconds is treated as seconds, multiplying by 1,000 pushes it far outside its intended date and may create an invalid date, while 1784370916 seconds treated as milliseconds lands only a few weeks after January 1970. Digit length is only a clue — negative values, historical timestamps, far-future dates, and leading zeros make length heuristics unreliable, so use the source API's schema.

Choose a date and time in Pick Date & Time. The browser interprets that wall-clock value in its local time zone, and you read Epoch (Seconds) or Epoch (Milliseconds). Epoch milliseconds are the JavaScript time value; epoch seconds are calculated with Math.floor(milliseconds / 1000), so sub-second precision is not shown in the seconds output.

The input control has no time-zone selector or offset. If a specification says "09:00 UTC" but your browser is set to Asia/Kolkata, entering 09:00 means 09:00 Asia/Kolkata — not UTC. Verify the intended time zone separately.

The UI labels the universal result GMT Date. For ordinary software timestamps, GMT and UTC are often used interchangeably as the zero-offset display, although they are not identical concepts in precision timekeeping. The local output depends on the device's time-zone configuration, the historical and current time-zone rules known to the browser, daylight-saving transitions, and locale/runtime date-string formatting.

Two users can see different local strings for the same timestamp while the instant remains identical, so use epoch values or an ISO 8601 string with Z or an explicit offset when exchanging instants between systems. Note that this tool does not output ISO 8601 directly — its universal display is a UTC/GMT date string, not 2026-08-20T12:00:00.000Z format.

The Current Epoch Clock updates once per second with Math.floor(Date.now() / 1000), showing whole seconds according to the device clock. It is useful for quick comparisons but is not a precision time source: device clocks can be wrong or drift, and browser scheduling can be delayed. Use a synchronized server or trusted time service for systems that require authoritative time.

The relative result compares the selected timestamp with Date.now() when the conversion runs, rounding into seconds, minutes, hours, or days:

12 minutes ago
in 3 days

This is an approximation: values are rounded, "day" is treated as 24 hours, calendar month and year differences are not calculated, and the value does not refresh every second automatically. Change the input or unit to recalculate, and use absolute timestamps for auditing, billing, legal deadlines, and scheduling logic.

Unix timestamps do not change when a user changes time zones; only the displayed local representation changes. That makes epoch values useful for storing instants such as an API request time, account creation, token expiration, or a job execution instant. Not every date/time is best modeled as an instant, though: "Every day at 09:00 Europe/London" is a recurring civil-time rule affected by daylight saving, and storing only one UTC offset does not capture the recurrence — save the relevant IANA time-zone identifier and scheduling intent.

A local wall-clock time can be ambiguous or nonexistent during daylight-saving transitions: when clocks move forward some times never occur, and when they move back the same local time can occur twice. The datetime-local field contains no zone, JavaScript applies browser rules when parsing it, and the UI does not let you choose the earlier or later occurrence. Negative Unix values represent instants before the epoch — entering -1 second produces the instant one second before 1970 UTC — but historical local-time output should be treated carefully, and downstream systems may reject negative timestamps even when JavaScript accepts them.

JavaScript numbers cannot represent every integer above Number.MAX_SAFE_INTEGER exactly, so very large millisecond values can lose integer precision before reaching the date constructor, and Date supports only a finite range beyond which values become invalid. The numeric input is processed with parseInt, so decimals are discarded, very large values can lose precision, and invalid or empty input clears the outputs. Validate ranges and types according to the destination system rather than assuming every integer is a supported timestamp.

Typical Unix time APIs do not represent leap seconds as a unique 23:59:60 timestamp; JavaScript Date follows ECMAScript time behavior rather than exposing leap seconds. Separately, the Year 2038 issue affects systems that store epoch seconds in a signed 32-bit integer, which overflows in January 2038. Modern JavaScript numbers are not limited to signed 32-bit seconds, so this converter can represent dates beyond that point — but the receiving database, embedded device, C library, or legacy API may still have a 32-bit limit. Conversion success does not prove downstream compatibility.

All conversions use the browser's built-in number and date functions. No date value needs to be submitted to a conversion API. Date inputs can still reveal schedules or operational information if shared through screenshots, clipboard history, or logs, so follow normal privacy practices.

Accuracy depends on the device clock and time-zone settings. Client-side processing does not make the device an authoritative clock.