Convert a Unix timestamp into a readable date, or a date back into a timestamp. Seconds, milliseconds and microseconds are detected from the digit count (and can be forced with the unit selector), and every result is shown in both your local time zone and UTC. A live clock keeps the current epoch time on screen, and all of it is computed in your browser — nothing is uploaded.
What is a Unix timestamp?
A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the moment known as the Unix epoch. Because it is a single number anchored to UTC, it carries no time zone, no daylight-saving rules and no formatting ambiguity — which is exactly why databases, log files, JWT tokens and HTTP APIs store time this way. Dates before 1970 are represented as negative numbers, and leap seconds are ignored by definition, so every day counts as exactly 86,400 seconds.
How to Convert a Unix Timestamp
- Paste the number — put your timestamp into the "Timestamp → Date" box. Leave the unit on Auto-detect and the digit count decides whether it is seconds, milliseconds or microseconds.
- Convert — click Convert to see that instant as local time, UTC, an ISO 8601 string and a plain-English "how long ago".
- Go the other way — in "Date → Timestamp", pick a date and time, choose whether you typed it in local time or UTC, and convert to get the timestamp in seconds and milliseconds.
- Copy — every result line has its own Copy button, and the live clock at the top can be copied in seconds or milliseconds.
Seconds, milliseconds or microseconds?
The quickest test is the digit count: a present-day timestamp is 10 digits in seconds, 13 in milliseconds and 16 in microseconds. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds; C's time(), PHP's time(), Python's time.time(), Go's Unix() and most SQL databases return seconds. Feeding a millisecond value into a seconds-based function is the classic bug behind a date landing tens of thousands of years in the future, so if a converted date looks absurd your value is almost certainly in milliseconds. Auto-detect handles the normal cases; use the unit selector when you want to force one.
Local time, UTC and ISO 8601
The timestamp itself is always UTC-based. The Local time line renders that same instant in your computer's time zone — including whatever daylight-saving offset applied on that date, not today's — while the UTC line shows it with no offset at all. The ISO 8601 line (for example 2026-08-22T02:00:00.000Z) is the machine-readable form to use in JSON and APIs; the trailing Z means UTC. All of these describe one and the same moment, which is why a timestamp copied between servers in different countries still refers to exactly the same instant.
The Year 2038 problem
Software that stores a timestamp in a signed 32-bit integer can count no higher than 2,147,483,647 seconds — which runs out at 03:14:07 UTC on 19 January 2038 and wraps around to 1901. That is why 64-bit timestamps became standard; modern systems are unaffected. Note the mirror-image limit at the other end: a signed 32-bit value cannot reach earlier than 13 December 1901 either. This converter uses JavaScript numbers, which cover roughly ±273,000 years around 1970, so dates far beyond 2038 convert normally.
Is my data uploaded?
No. Every conversion runs entirely in your browser using the built-in Date and Intl APIs — nothing is sent to a server, and the page keeps working offline once loaded. Your local time zone is read from your own system settings (it is shown next to the local result) rather than looked up over the network, so no location data leaves your device. If a value can't be converted — empty input, non-numeric text, or a number outside the range JavaScript's Date can represent — you get a clear message instead of a wrong date.