Convert between Unix epoch timestamps and human-readable dates. Seconds and milliseconds are detected automatically, and every result is shown as UTC, local time, ISO 8601 and a relative label such as three hours ago.

How to use it

  • Paste an epoch value to expand it into readable dates, or pick a date to get the epoch back.
  • Press Now to capture the current instant.
  • Compare the UTC and local rows whenever a bug might be timezone-related.

Seconds, milliseconds and why detection matters

Unix time counts from midnight UTC on 1 January 1970. The ambiguity that causes most bugs is unit: POSIX and most databases count seconds, while JavaScript, Java and many APIs count milliseconds. Both are bare integers, so nothing in the value itself announces the unit, and mixing them silently throws dates around by a factor of a thousand. A ten-digit value is seconds and lands in the present era; a thirteen-digit value is milliseconds. Interpreting a seconds value as milliseconds puts you in January 1970; the reverse lands you tens of thousands of years in the future. This converter checks magnitude and tells you which it assumed.

Timezones, ISO 8601 and the 2038 problem

An epoch timestamp has no timezone. It is an absolute instant, and a timezone is only applied when rendering it for a human. This is precisely why storing timestamps as epoch or as UTC is the right default, and why storing local wall-clock strings without an offset creates data that cannot be interpreted reliably once daylight saving shifts. ISO 8601 is the format to use when you must move a timestamp as text: 2026-07-05T09:30:00Z is unambiguous because the trailing Z pins it to UTC.

One limit worth knowing: systems that store Unix time in a signed 32-bit integer overflow on 19 January 2038, wrapping to 1901. Modern platforms use 64-bit time and are unaffected, but embedded devices, old file formats and legacy database columns still carry the flaw. Every conversion here is computed in your browser, so nothing you paste is transmitted.

Frequently asked questions

Why does my timestamp show a different day than expected?

Almost always a timezone boundary. An instant late in the evening UTC is already the next day east of Greenwich and still the previous day in the Americas. Compare the UTC and local rows; if they straddle midnight, that is your answer.

Do epoch timestamps account for leap seconds?

No. Unix time deliberately pretends every day is exactly 86,400 seconds, so a leap second is absorbed rather than represented. This keeps arithmetic simple at the cost of not being a true count of elapsed SI seconds.

Is the date I enter sent anywhere?

No. The conversion is local to your browser, so timestamps taken from logs or incident timelines stay on your machine.

Related tools: Cron Explainer, JWT Decoder, UUID Generator.