A Unix timestamp is just a number, which makes it perfect for computers and useless for humans. When you see 1722510000 in a log, a database row, or a JWT, you need to turn it into a real date to know what happened and when. This guide shows how to convert a Unix timestamp to a date both ways, and how to avoid the two mistakes that trip everyone up.
What a Unix timestamp is
A Unix timestamp counts the seconds that have passed since the epoch, which is 1970-01-01 00:00:00 UTC. So 0 is the start of 1970, and a value like 1722510000 is a moment in 2024. The count is always measured in UTC, which is what keeps it unambiguous no matter where the server or user sits.
Because it is a plain integer, a timestamp sorts, compares, and stores cleanly. The catch is that it tells you nothing readable until you convert it.
Seconds or milliseconds
This is the most common source of bugs. The Unix standard uses seconds, but JavaScript’s Date object uses milliseconds, and so do many modern APIs.
- A 10-digit number is seconds (for example
1722510000). - A 13-digit number is milliseconds (for example
1722510000000).
If your date lands in the year 1970, you almost certainly passed seconds where milliseconds were expected, or the reverse. A quick way to convert in code: multiply seconds by 1000 to get milliseconds, or divide by 1000 to go back.
UTC vs local time
A timestamp itself has no timezone, it is always UTC. The timezone only appears when you format it for a human. The same 1722510000 can read as a different wall-clock time in New York, London, or Tokyo even though it is the exact same instant.
When debugging, always note whether a displayed date is UTC or your local time, otherwise you will chase an “off by a few hours” ghost that does not exist.
Convert it in three steps
- Open the Unix Timestamp Converter and paste your number.
- Confirm whether it is seconds or milliseconds, then read the human date in both UTC and your local time.
- To go the other way, enter a date and copy the timestamp it produces.
Everything runs locally in your browser, so your data and timestamps are never uploaded anywhere.
The year 2038 problem
Older systems store timestamps as a 32-bit signed integer, which can only count up to 2147483647. That value is reached on 2038-01-19 03:14:07 UTC, and one second later the counter overflows into a negative number and wraps back to 1901. This is the Y2K38 problem. Modern languages and 64-bit systems use a wider integer that pushes the limit billions of years out, but legacy databases and embedded devices can still hit the wall. If you work with old systems, it is worth checking the integer width.
When a converted date looks wrong, check the digit count and the timezone first. With the Unix Timestamp Converter you can paste a value, see both interpretations side by side, and stop guessing.
Related tools
- Scheduling something on a recurring basis? Decode the syntax with the Cron Expression Explainer.
- Want to see that timestamp in hex or binary? Use the Number Base Converter.
- Generating unique ids alongside your timestamps? Try the UUID Generator.
Count the digits, mind the timezone, and the number turns into a date in seconds.