Unix Timestamp Converter
Convert Unix timestamps to dates and back — 10-digit seconds or 13-digit milliseconds, in any timezone.
FAQ
What is the difference between 10-digit and 13-digit timestamps?
10 digits means seconds, 13 digits means milliseconds (used by JavaScript and Java). Drop the last three digits of a millisecond value to get the seconds version.
Is a Unix timestamp UTC or local time?
A Unix timestamp is an absolute count of seconds since 1970-01-01 00:00:00 UTC, so the same digits mean the same instant anywhere. A timezone only matters when it is rendered as a date, which is why the output lists local time plus UTC, Beijing, Tokyo, London and New York.
What is the year 2038 problem?
Storing seconds in a signed 32-bit integer overflows after 2147483647, which is 2038-01-19 03:14:07 UTC. Storing 64-bit values or milliseconds avoids it.
How do I get the current timestamp?
The current seconds and milliseconds values are shown live at the top of the page — click to copy.
About this tool
Three things on one page: the live current timestamp, timestamp to date, and date to timestamp. Everything runs locally, so it works offline.
Seconds versus milliseconds: a value below 1e11 is read as seconds, which means 12 or more digits are treated as milliseconds. That makes both the 10-digit 1780000000 (2026) and the 13-digit 1780000000000 paste-ready. An 11-digit value is genuinely ambiguous and is read as seconds (roughly the year 2286) - add or drop three digits yourself in that case. Earlier versions used a 1e12 threshold, which turned the millisecond value for 2000-01-01 (946684800000) into the year 31969.
A timestamp has no timezone: it is simply the count of seconds since 1970-01-01 00:00:00 UTC. The output therefore shows local time plus a comparison across UTC, Beijing, Tokyo, London and New York. London and New York shift with daylight saving, which is why they are labelled UTC+0/+1 and UTC-5/-4. Beijing has no DST and stays at UTC+8.
The year 2038 problem: storing seconds in a signed 32-bit integer tops out at 2147483647, which is 2038-01-19 03:14:07 UTC, after which it wraps negative. The reverse conversion warns when the second value passes that limit. Conversion here uses floating-point seconds with Math.floor, so dates far past 2038 stay correct - the older 32-bit truncation showed negative seconds for them.
The reverse conversion uses the browser's timezone and there is no timezone selector: to get the seconds for a UTC instant, fold the offset in yourself (for example enter 20:00 local for 12:00 UTC at UTC+8) or it will be hours off. The live counter refreshes every second and the copy button copies the 13-digit millisecond value; drop the last three digits for the 10-digit form.