Epoch Converter: Unix Timestamp to Date and Back

Convert between a Unix timestamp and a human-readable date, either direction.

A raw Unix timestamp doesn't say whether it's counting seconds or milliseconds, and guessing wrong turns 2024 into the year 1970 or the year 47000. This converter infers which one you pasted from the digit count, shows the resulting instant across five real timezones at once, and gives you a live relative-time phrase like "3 hours ago" that keeps ticking rather than freezing at the moment you pasted it.

What is Unix epoch time?

Unix time counts the seconds that have passed since 00:00:00 UTC on January 1, 1970, a moment called the Unix epoch. It pretends every day is exactly 86,400 seconds long, so leap seconds are left out: the count lines up neatly with UTC calendar dates, but around a leap second one timestamp covers two real seconds.

A present-day timestamp in seconds has ten digits, such as 1700000000, which is 22:13:20 UTC on November 14, 2023. JavaScript, Java and many web APIs count milliseconds instead, adding three digits, so 1700000000000 names the same instant. That difference in length is precisely what this converter uses to tell the two apart.

How to convert a Unix timestamp to a date

  1. Paste the timestamp into the Unix timestamp field; a 10-digit value is read as seconds and a 13-digit value as milliseconds, shown in the Detected precision chip.
  2. Read the same instant rendered in all five time zones side by side, with the exact ISO 8601 string in UTC underneath.
  3. Check the relative phrase next to it (for example "3 days ago") to confirm the value is in the range you expected.
  4. To go the other way, pick a date and time in the Date → Timestamp panel; it is read in your local time zone and returned as both seconds and milliseconds.

Seconds or milliseconds — how the guess actually works

The precision detector runs the same digit-based pattern the site's own omnibox uses to recognize a timestamp elsewhere, so the two never disagree about what a given string means. A ten-digit value like 1700000000 reads as seconds; a thirteen-digit value like 1700000000000 reads as milliseconds, which is the pattern current Unix time actually falls into for both units right now.

A digit count outside those two canonical lengths — nine digits or eleven, for instance — falls back to a simple length heuristic rather than the shared pattern, since that pattern deliberately doesn't classify non-canonical lengths. If your detected precision looks wrong for an unusual timestamp, that's the edge case to double-check by hand.

Five timezones, shown together

Once a timestamp parses, its instant is rendered in UTC, New York, Los Angeles, London, and Tokyo simultaneously, using the browser's Intl.DateTimeFormat with each zone's own identifier rather than a fixed offset — so London's row correctly reflects British Summer Time or GMT depending on the date, instead of being permanently off by an hour half the year.

That list of five is fixed; there's no arbitrary-timezone picker. If you need a zone not in that list, the raw ISO 8601 string shown alongside the relative-time phrase is in UTC and can be fed into any other timezone-aware tool to get the specific offset you're after.

The relative-time phrase keeps counting

"3 hours ago" or "in 12 minutes" is recomputed once a second against the current time rather than calculated once when you paste the timestamp, so leaving the tab open updates the phrase continuously instead of leaving it stale after a few minutes. Negative timestamps work in the other direction too: a value before zero represents a date before January 1, 1970, and converts and displays the same way a post-1970 value does.

Converting a date back to a timestamp

The date-to-timestamp direction takes a date and time you enter in your browser's own local timezone through a standard datetime-local picker, and returns both the seconds and milliseconds forms side by side. Because the input is interpreted in your local zone rather than UTC, converting the same wall-clock time from two different timezones on purpose will correctly produce two different timestamps — that's not a bug, it reflects that the same clock reading means a different instant depending on where you are.

Get the current epoch time in code

Common time spans in seconds

The Year 2038 problem

Software that stores Unix time in a signed 32-bit integer can count only up to 2,147,483,647, which is 03:14:07 UTC on January 19, 2038. One second later the value wraps around to -2,147,483,648, and such a program reads the date as December 13, 1901.

Moving to 64-bit timestamps, which current operating systems, databases and languages largely have, pushes the limit roughly 292 billion years out. You can inspect both edges here: paste 2147483647 or -2147483648 and the five timezone rows show exactly when each one falls.

Questions people ask about Epoch / Unix Timestamp Converter

How do I know if my timestamp is in seconds or milliseconds?
Paste it in and check the detected-precision chip next to the input. It's inferred from digit count: ten digits reads as seconds, thirteen digits reads as milliseconds, matching how current Unix time actually looks in each unit. An unusual digit count outside those two lengths falls back to a length-based guess, which is worth double-checking manually.
Can this convert a timestamp to a timezone that isn't listed?
Not directly — only five fixed zones (UTC, New York, Los Angeles, London, Tokyo) are shown. The ISO 8601 string displayed alongside the relative-time phrase is in UTC, though, and can be converted to any other zone using a separate timezone tool if you need one outside that list.
Does the converter handle timestamps before 1970?
Yes. A negative Unix timestamp represents a date before January 1, 1970, and it parses and displays through the same detection and conversion logic as a positive one, including the relative-time phrase and the five-timezone breakdown.
Why did converting the same date and time give a different timestamp on another computer?
The Date to Timestamp field is interpreted in your own browser's local timezone, not UTC. The identical wall-clock date and time typed on a machine in a different timezone corresponds to a different actual instant, so the resulting timestamp legitimately differs between the two.
What is the Unix epoch?
It is the fixed starting point Unix time counts from: 00:00:00 UTC on Thursday, January 1, 1970. Timestamp 0 is that instant, positive values fall after it, and negative values, which this converter accepts too, fall before it.
What happens to Unix timestamps on January 19, 2038?
At 03:14:08 UTC that day the count passes the largest number a signed 32-bit integer can hold. Programs still storing time that way overflow and jump back to 1901, while anything using 64-bit time, including the JavaScript Date object this page relies on, keeps working normally.
Does Unix time include leap seconds?
No. Unix time assumes every day has exactly 86,400 seconds, so the leap seconds inserted into UTC since 1972 are never counted. Subtracting two timestamps that straddle a leap second therefore gives an answer one second short of the true elapsed time.
How do I get the current Unix timestamp in JavaScript or Python?
In JavaScript, Date.now() returns milliseconds and Math.floor(Date.now() / 1000) gives seconds. In Python, run import time and then int(time.time()) for seconds or int(time.time() * 1000) for milliseconds. Paste either number into the converter to confirm which unit it is.

Related tools on BrakeTools

Content reviewed 2026-09-27.