Unix Timestamp Converter
How it works
The factor-of-1000 bug
Unix time is seconds since 1970-01-01T00:00:00Z; JavaScript's Date.now() returns milliseconds. Feed seconds where milliseconds are expected and every date lands in January 1970; feed milliseconds as seconds and dates land around the year 57000. This tool picks the unit from the input and always says which reading it chose whenever the input is not a plain 10-digit seconds value, so an ambiguous 11- or 12-digit value is never converted silently.
How the unit is detected
Up to 12 integer digits below 1e11 are seconds; 13 digits (or a magnitude of at least 1e11) are milliseconds; 16 digits (or at least 1e14) are microseconds, the unit of Python's time.time_ns() // 1000, PostgreSQL and many tracing systems; 19 digits (or at least 1e17) are nanoseconds, the unit of Go's UnixNano, time.time_ns() and OpenTelemetry. Today's values are 10, 13, 16 and 19 digits long. Integers are converted exactly with BigInt, so a 19-digit nanosecond value keeps every digit instead of being rounded to the nearest double.
Local time, DST and relative time
The breakdown shows the instant in your browser's time zone as an ISO 8601 string with its offset (2025-07-08T11:40:00-07:00), the IANA zone name and offset, and DST when that zone is on daylight saving time at that instant - the offset is looked up for the instant itself, not for today, so a July timestamp viewed in January still shows summer time. Relative time ('3 months ago', 'in 2 hours') is measured against the moment you typed. The live NOW counter at the top shows the current unix time in seconds; USE copies it into the input and PAUSE freezes it.
Why only ISO 8601 is accepted
ECMAScript defines parsing only for ISO 8601. Everything else - 'July 10 2026', '10/07/2026', RFC 2822 - is implementation-defined: engines may disagree or reject it, and 10/07 is July or October depending on locale assumptions. This tool therefore rejects non-ISO strings instead of guessing. Two ISO rules worth knowing: a date-only string like 2026-07-10 is UTC midnight per the standard, and a date-time without a timezone is rejected here because the standard says to read it as local time, which produces different results on every machine.
Examples
| 1752000000 | 2025-07-08T18:40:00Z |
| 1752000000000 | 2025-07-08T18:40:00Z (read as milliseconds) |
| 1752000000123456 | 2025-07-08T18:40:00.123456Z (read as microseconds) |
| 1752000000123456789 | 2025-07-08T18:40:00.123456789Z (read as nanoseconds, every digit kept) |
| 2026-07-10 | 1783641600 (UTC midnight per the standard) |
| -86400 | 1969-12-31T00:00:00Z (pre-1970 is valid) |
FAQ
What is the current unix timestamp?
The NOW counter at the top of this page shows it live, in seconds, ticking once per second from your device clock. Press USE to convert it. In code: Math.floor(Date.now() / 1000) in JavaScript, int(time.time()) in Python, date +%s in a shell.
Why does my timestamp show January 1970?
You passed unix seconds to something expecting milliseconds. new Date(1752000000) is 1970-01-21T06:40:00Z because JavaScript reads the argument as milliseconds. Multiply seconds by 1000: new Date(1752000000 * 1000) is 2025-07-08T18:40:00Z.
How does auto-detection decide seconds, milliseconds, microseconds or nanoseconds?
By integer digit count or magnitude: 13 digits or at least 1e11 is milliseconds, 16 digits or at least 1e14 is microseconds, 19 digits or at least 1e17 is nanoseconds, anything smaller is seconds. Current values are 10, 13, 16 and 19 digits (seconds stay 10 digits until the year 2286). Whenever the input is not exactly 10 digits, the note states which reading was applied.
Why is '2026-07-10T12:00:00' without a timezone rejected?
ISO 8601 says a date-time without an offset is local time. Local to whom? The same string names a different instant on every machine, so this tool refuses to guess - add Z for UTC or an explicit offset like +08:00. Date-only strings are different: the standard fixes them at UTC midnight, so 2026-07-10 is accepted.
Are negative timestamps valid?
Yes - they count backwards from 1970. -86400 is 1969-12-31T00:00:00Z. JavaScript dates span about 271821 BC to 275760 AD (plus or minus 8.64e15 milliseconds); beyond that this tool reports out of range.
Is my timestamp uploaded to a server?
No. The page ships a strict Content-Security-Policy: connect-src 'none' blocks fetch, XHR, WebSockets and beacons, while default-src 'self' and form-action 'none' block every other way markup could send data off-site. Conversion happens in your browser and cannot leave it.