Overview
A Unix timestamp is just a count of seconds since 1970-01-01 UTC, which makes it easy for machines and unreadable for humans. This converter goes both directions: paste an epoch value to see what date it really is, or turn a calendar date into the integer your database or API expects.
How It Works
Entering an epoch value in seconds renders the UTC standard representation alongside your local browser time, so the offset causing the bug is visible immediately. Running it in reverse gives three forms of the same instant: epoch seconds, the same value in milliseconds, and the ISO 8601 UTC string, each with its own copy button. The Current Time button stamps in the present moment as Math.floor(Date.now() / 1000).
Step-by-Step Usage Guide
- Paste an epoch value, or click Current Time to start from now.
- Read the UTC standard representation to see the true instant, independent of your machine timezone.
- Switch direction to convert a calendar date back into an integer.
- Copy the seconds, milliseconds, or ISO UTC form depending on what the consuming system expects.
Technical Specifications & Standards
The seconds-versus-milliseconds distinction is the single most common source of timestamp bugs. Unix tooling, Postgres to_timestamp, and JWT exp and iat claims all use seconds. JavaScript Date.now(), Java System.currentTimeMillis(), and many JSON APIs use milliseconds. A millisecond value read as seconds lands roughly 50,000 years in the future; a seconds value read as milliseconds lands in January 1970. Both failures are obvious here because the output shows the resolved calendar date rather than just reformatting the number.
Targeted Use Cases
- Decoding exp and iat claims from a JWT to work out whether a token expired or a clock skewed.
- Reading raw timestamp columns out of a database dump or a log line during an incident.
- Checking whether an API returns seconds or milliseconds before writing the parsing code.
- Building a fixed timestamp for a test fixture that must not drift.
Notes & Gotchas
- If the resolved date lands in 1970 you passed milliseconds to something expecting seconds. If it lands tens of thousands of years out, you did the reverse.
- Epoch values carry no timezone. The offset appears only when you format them, which is why the UTC representation is the one to compare against another system.
- Timestamps do not encode leap seconds. A Unix day is always exactly 86,400 seconds, so subtracting two epochs gives elapsed civil time, not elapsed physical time.
- Negative epoch values are valid and represent dates before 1970.
Frequently Asked Questions
Does this convert in both directions?
Yes. Epoch to date, and date back to epoch. The reverse direction returns seconds, milliseconds, and the ISO 8601 UTC string together.
Why does my timestamp show a different time than my colleague's?
Almost always a timezone rendering difference rather than a data difference. Compare the UTC representation instead of the local one.
Is the year 2038 problem relevant here?
Only for systems storing the epoch in a signed 32-bit integer, which overflows on 19 January 2038. This tool uses JavaScript numbers, so it handles values well beyond that.
Does my input get uploaded anywhere?
No. The conversion is arithmetic performed in the page and nothing is sent to a server.