Convert Unix timestamps to readable dates
Translate epoch timestamps to human dates and back, with full timezone support, ISO 8601 output, and millisecond precision. Useful any time you're debugging logs, comparing API timestamps, or scheduling work across regions.
Unix epoch time — also called Unix time, POSIX time, or simply 'a timestamp' — is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970, ignoring leap seconds. It's the most common way computers represent a point in time, because it's a single integer that's easy to compare, store, and transmit.
Most databases, log files, JWT tokens, and APIs use Unix timestamps internally. The trade-off is that they're meaningless to humans: '1713744000' tells you nothing on its own, but it converts to a real date that you can reason about.
Unix timestamps come in two common flavors. Seconds-precision timestamps are 10 digits long today (e.g. 1713744000) — used by classic Unix systems, JWT 'iat' and 'exp' fields, and most database TIMESTAMP columns. Millisecond-precision timestamps are 13 digits long (e.g. 1713744000000) — the default in JavaScript's Date.now(), Java, and many modern APIs.
Our converter auto-detects which one you pasted based on length and converts accordingly. It also shows both formats in the output so you can grab whichever your system expects.
A Unix timestamp itself has no timezone — it's a count of seconds since a fixed point in UTC. Timezones only matter when you display the timestamp as a date. Our converter lets you pick the display timezone independently of your local timezone, so you can answer questions like 'what time was this log entry in our user's local time?' or 'when does this token expire in Tokyo?'
For the reverse direction (Date → Timestamp), pick the timezone the date is in. If the date came from a UTC log, set the input timezone to UTC. If it's a wall-clock time from a meeting invite, use the relevant local timezone.
Systems that store Unix timestamps as signed 32-bit integers will overflow on January 19, 2038 at 03:14:07 UTC — the largest representable value is 2,147,483,647. After that point the timestamp wraps to a negative number, suddenly placing the date in 1901. This affects legacy hardware, embedded systems, and any code still using 32-bit time_t.
Modern 64-bit systems are safe for hundreds of billions of years. The Quick Reference panel above includes this exact moment as a useful test case.
Three common culprits. First, you might have seconds vs milliseconds confusion — multiplying or dividing by 1000 fixes most cases. Second, the source system might be using local time as if it were UTC (a subtle bug that's surprisingly common). Third, daylight saving transitions can introduce off-by-an-hour errors near the spring/fall changeover.
If you're still unsure, paste the timestamp here and try different display timezones — if one of them produces the expected wall-clock time, that's the timezone your source system is actually using.