Timestamp Converter
Unix epoch ⇄ ISO 8601 and human time, in seconds or milliseconds, UTC and local.
Runs entirely in your browser — nothing you paste is uploaded.
About Timestamp Converter
A Unix timestamp is the number of seconds since midnight UTC on 1 January 1970. It's what databases store, what JWTs use for `iat` and `exp`, and what every log line you'll ever grep is stamped with — and it's completely unreadable to a human, which is what this fixes.
Paste a number and the units are detected: ten digits is seconds, thirteen is milliseconds, and getting that wrong is how a date lands in 1970 or in the year 54,000. You get back the ISO 8601 string, the UTC form, your local time with its offset, and a relative description like '3 hours from now'. Paste a date instead and it goes the other way.
The live epoch clock at the top is there for the times you just need 'now' as a number to paste into a query or a test fixture, without opening a REPL.
The distinction worth internalising: a Unix timestamp is an instant, not a date. It has no timezone — the timezone appears only when you format it for a human. Storing local time in a database and reasoning about it later is where almost every date bug comes from. Store the instant, format at the edge.
Frequently asked
›Seconds or milliseconds?
Unix time is defined in seconds, which is what most backends, JWTs and databases use. JavaScript's `Date.now()` returns milliseconds. Ten digits is seconds; thirteen is milliseconds. Mixing them up shifts a date by a factor of a thousand, which is very obvious once it happens and very easy to do.
›What is the year 2038 problem?
A signed 32-bit integer overflows at 03:14:07 UTC on 19 January 2038, wrapping to 1901. Anything still storing timestamps in a 32-bit signed field will break then. Modern systems use 64-bit values, which last around 292 billion years.
›Does a Unix timestamp have a timezone?
No. It's a count of seconds from a fixed UTC instant. Timezones exist only in the formatting step. This is why storing timestamps rather than local date strings avoids an entire category of bug.
›What about leap seconds?
Unix time ignores them by definition — every day is exactly 86,400 seconds. A leap second is absorbed by repeating or skipping a value, so Unix time is not a true count of elapsed SI seconds since the epoch. It almost never matters, and when it does you need TAI, not Unix time.
›Which ISO 8601 format should I use?
`2026-09-05T14:30:00Z` — full date, `T` separator, `Z` for UTC. Avoid formats with local offsets when storing, and avoid ISO week dates unless something specifically wants them. RFC 3339 is the stricter subset most APIs actually mean when they say ISO 8601.