"category": "dev-utility",
Unix Timestamp Converter
"tldr": Paste a Unix timestamp or a date string and get every format at once - ISO 8601, seconds, milliseconds, UTC, and your local time - with a live current-time ticker.
Convert between Unix timestamps and human dates in both directions: paste epoch seconds, milliseconds (auto-detected by digit count), or any date string, and get ISO 8601, both epoch precisions, UTC, your local time, and a relative "3 days ago" - plus the live current epoch, ticking.
The classic bug this page debugs daily: seconds vs milliseconds confusion. A seconds value parsed as milliseconds lands in January 1970; milliseconds parsed as seconds lands tens of thousands of years out. The converter tells you explicitly which interpretation it applied, so the mismatch is visible instead of mysterious.
How to convert a timestamp
- 1Paste a Unix timestamp (seconds or milliseconds - detected automatically) or a date string.
- 2Every representation is shown at once, each with its own copy button.
- 3The "interpreted as" note tells you whether input was read as seconds, ms, or a date.
- 4Use the live ticker's "Use" button to convert the current moment.
Convert Timestamp to All formats in code
Math.floor(Date.now() / 1000); // current epoch seconds
new Date(1704067200 * 1000).toISOString(); // seconds -> ISOfrom datetime import datetime, timezone
datetime.fromtimestamp(1704067200, tz=timezone.utc)
int(datetime.now(tz=timezone.utc).timestamp())Frequently asked questions
My date shows as January 1970 or year 57000 - what happened?
Units mismatch. Near-1970 means a seconds value was treated as milliseconds somewhere (divided 1000x); a far-future year means the reverse. Rule of thumb: current epochs are 10 digits in seconds, 13 in milliseconds - this converter applies that heuristic and tells you which it chose.
Is a Unix timestamp timezone-dependent?
No - it counts seconds since 1970-01-01T00:00:00 UTC, everywhere. Timezones only enter when *rendering* it as a local date. That is why storing epochs (or ISO 8601 with offset) beats storing local datetime strings: the moment is unambiguous.
What happens in 2038?
Signed 32-bit epoch counters overflow on 2038-01-19 - the "Y2038 problem" for legacy C systems and old database columns. Anything using 64-bit time (all modern platforms, JavaScript numbers, this tool) is fine for another 290 billion years.
Last updated:
You might also need
Free and in-browser, like everything on JSON Console. Browse all tools →