Unix Timestamp Converter

Read an Epoch Value Without Guessing

A Unix timestamp identifies an instant by counting from 1970-01-01T00:00:00Z, the Unix epoch. Backend logs, JWT claims, webhook payloads, database records, and JavaScript APIs often represent that count as either seconds or milliseconds. Those units describe the same timeline but differ by a factor of 1,000. For example, 1704067200 seconds and 1704067200000 milliseconds both represent January 1, 2024 at midnight UTC.

This Unix timestamp converter handles both directions: epoch to date and date to epoch. It also shows a live Unix clock, which is useful when creating a test expiration value or checking whether a remote service clock is roughly aligned with the browser.

The live panel displays whole epoch seconds, the current three-digit millisecond portion, and a UTC date string. Pause freezes the displayed instant; Resume starts it again. Copy Seconds copies the floored whole-second value, while Copy Milliseconds copies the complete value returned by the browser clock. Pausing matters when several fields in a bug report need to refer to one reproducible instant.

Converting a Unix Timestamp to a Date

Enter a numeric value under Unix Timestamp to Date, then choose Auto-detect, Seconds, or Milliseconds. The conversion updates immediately. A valid result includes:

• the unit the tool interpreted;
• a short relative description such as in 12 minutes, yesterday, or 413 days ago;
• UTC date and time;
• local date and time using the browser’s timezone;
• an ISO 8601 UTC string;
• leap-year status, day of year, ISO-style week number, and weekday.

Each full date representation has its own copy control. Use the ISO result for APIs and structured data because strings such as 2024-01-01T00:00:00.000Z are unambiguous. Use UTC when correlating infrastructure logs. The local string is more convenient for explaining an event to someone working in the same timezone, but it includes browser- and locale-dependent formatting.

Auto-detection is value based, not strictly digit based. Values greater than 99,999,999,999 are treated as milliseconds; lower values are treated as seconds. That works for ordinary contemporary timestamps, but explicit selection is safer for historical millisecond values close to the epoch and unusual far-future second values. A negative number is interpreted as seconds in Auto-detect and points to an instant before 1970. Decimal input is accepted numerically, although output formatting ultimately follows JavaScript Date precision.

Worked debugging example

Suppose an API returns 1719837296123. Auto-detect labels it milliseconds. The ISO line gives the canonical UTC instant, while the local line answers “what time was that on this computer?” If a log system instead records 1719837296, explicitly selecting Seconds produces approximately the same instant but without the final 123 milliseconds. A 1,000-fold discrepancy that lands in 1970 or thousands of years ahead almost always indicates a seconds-versus-milliseconds mistake.

The relative label is deliberately approximate. It rounds to the nearest second, minute, hour, or day and compares against the current browser time. It is excellent for spotting an expired token or a job scheduled tomorrow, but it should not replace an exact duration calculation or contractual deadline.

Turning Date Parts Into Epoch Time

The Date to Unix Timestamp side uses separate fields for year, month, day, hour, minute, and second. Select Local when the entered wall-clock values belong to the browser’s local timezone, or UTC when they already describe UTC. Set to Current Date/Time refreshes all fields according to the selected timezone mode. The tool returns copyable epoch values in both seconds and milliseconds.

Timezone choice changes the result. Entering 09:00 as Local on a UTC+05:30 computer describes an instant five and a half hours earlier than entering 09:00 as UTC. If a specification says “2026-08-17 09:00Z,” choose UTC. If a support ticket says “the user clicked at 9 AM local time,” choose Local only when your browser is configured to that user’s timezone; this control cannot choose an arbitrary IANA region.

The numeric fields constrain month to 1–12, day to 1–31, and clock fields to normal ranges. They do not validate every calendar combination as a human calendar form would. JavaScript normalizes overflow dates. Entering April 31 can roll into May rather than displaying a dedicated “April has 30 days” warning. Verify the resulting date with the timestamp-to-date side whenever the source date may be malformed.

Where Epoch Conversion Helps

Token inspection. JWT exp, iat, and nbf claims are conventionally NumericDate values in seconds. Paste an exp claim, force Seconds, and compare its relative label with now. Do not assume a 13-digit JavaScript timestamp can be placed directly in a JWT claim.

Database checks. SQL schemas may store seconds in an integer, milliseconds in a bigint, or a native timestamp. Convert a sample and document the unit alongside the column. The number alone carries no unit metadata.

Frontend scheduling. JavaScript’s Date.now() returns milliseconds. Many Unix command-line tools and server libraries return seconds. Copy the correct live value before building expiresAt, cache TTL, or retry test data.

Incident timelines. Copy ISO 8601 UTC values into an incident document so events from several regions sort consistently. Local rendering can remain a secondary annotation.

Interpretation Notes and Edge Cases

Unix time does not encode a timezone. An epoch value is an instant; UTC and local strings are two views of that instant. Appending a timezone offset to the raw integer is therefore meaningless. Timezone rules matter when converting wall-clock date parts into the instant, not when storing the epoch count.

POSIX-style Unix time does not count leap seconds as distinct numbered seconds. It is suitable for normal application chronology, but not for high-precision astronomical or timekeeping analysis. The browser also limits the representable Date range. Extremely large values may produce no valid result.

The calendar detail cards use browser date operations. Day of year compensates for local daylight-saving offset changes, and the week card follows a Monday-based ISO week calculation. Around a UTC/local date boundary, calendar labels can reflect local date getters even while the main ISO result is UTC. Treat the copied ISO string as the canonical cross-system representation.

Common interval cards list 60 seconds per minute, 3,600 per hour, 86,400 per day, and 604,800 per week. “30-day month” and “365-day year” are convenient fixed-duration approximations, not calendar arithmetic. A civil day crossing a daylight-saving transition may contain 23 or 25 elapsed hours in local time.

Common Input Mistakes

• Pasting a value with commas, surrounding prose, or a unit suffix. Enter only the numeric value.
• Choosing milliseconds for a ten-digit contemporary seconds value, which pushes the result near January 1970.
• Treating local output from one computer as portable. Different browser timezone settings produce different local strings.
• Rounding milliseconds to seconds when sub-second ordering is important. The seconds output is floored.
• Using the approximate relative label as evidence of an exact SLA interval.
• Entering a nonexistent calendar date and overlooking JavaScript’s normalization.

Unix Timestamp Converter FAQ

Does a Unix timestamp always have 10 digits?

No. Contemporary positive seconds commonly have 10 digits and milliseconds commonly have 13, but historical, negative, and far-future values differ. Select the unit explicitly when context supplies it.

Why do UTC and Local show different hours?

They render the same instant under different timezone rules. UTC uses offset zero; Local uses the timezone configured in the browser or operating system.

Can I convert microseconds or nanoseconds?

Not directly. The available scales are seconds and milliseconds. Divide microseconds by 1,000 or nanoseconds by 1,000,000 before selecting milliseconds, understanding that browser date precision will discard finer detail.

Why did an invalid date become another date?

The date-fields conversion relies on the JavaScript Date constructor, which normalizes some overflows. Check month lengths and leap days before using the result.

Is the live clock synchronized to an atomic clock?

No. It reflects the device clock available to the browser. Network clock drift or an incorrectly configured system clock will appear in the displayed epoch.

Which output should I paste into an API request?

Follow the API contract. Use seconds for specifications that say Unix seconds or NumericDate, milliseconds for JavaScript-style epoch milliseconds, and ISO output only where an ISO 8601 string is expected.