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 reads 13 integer digits (or any magnitude of at least 1e11) as milliseconds and tells you which reading it chose, so an ambiguous 11-digit value is never converted silently.
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) |
| 2026-07-10 | 1783641600 (UTC midnight per the standard) |
| -86400 | 1969-12-31T00:00:00Z (pre-1970 is valid) |
FAQ
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 vs milliseconds?
13 integer digits, or any magnitude of at least 1e11, is read as milliseconds; otherwise seconds. Current unix seconds are 10 digits (and stay 10 until the year 2286); current milliseconds are 13. 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.