Open almost any API response, database row, or log file and you will find dates stored as a plain number like 1751554800. That is a Unix timestamp, and it is the most common way computers record a moment in time. It looks cryptic, but the idea behind it is simple, and a couple of gotchas cause most of the bugs.
What a Unix timestamp actually is
A Unix timestamp is the number of seconds that have elapsed since a fixed starting point: midnight UTC on 1 January 1970, known as the Unix epoch. So 0 is that exact instant, 60 is one minute later, and 1751554800 is a specific moment in 2025. Because it is just a count of seconds from one agreed-upon origin, it is unambiguous and easy for computers to compare, sort, and do arithmetic on. That is why it shows up everywhere instead of a human-readable date.
Seconds vs milliseconds: the bug that bites everyone
Here is the single most common source of timestamp bugs. Unix time is traditionally counted in seconds, which gives a 10-digit number today. But JavaScript and many other environments count in milliseconds, which is 1000 times larger and gives a 13-digit number. Mix them up and your date lands in the wrong era entirely: read a seconds value as milliseconds and you get a moment in 1970; read a milliseconds value as seconds and you land tens of thousands of years in the future.
The quick check is the digit count. A current timestamp in seconds has 10 digits; in milliseconds it has 13. If a converted date looks absurd, this mismatch is almost always why. A good timestamp converter detects which unit you pasted and shows the human date both ways so you can spot the error immediately.
UTC vs local time
A Unix timestamp itself has no time zone. It marks one absolute instant, measured from a UTC origin. The confusion appears when you turn it into a readable date, because the same timestamp displays as different clock times depending on the viewer's time zone. A moment that reads as 3 PM in London reads as 10 AM in New York, even though it is the exact same instant and the exact same number.
This is why a timestamp can look like it is off by several hours, or even land on the wrong calendar day near midnight, when you compare what your server logged against what your local machine shows. Nothing is wrong; you are just seeing one instant expressed in two zones. When you need to be precise, convert with UTC explicitly so everyone is reading from the same reference.
The year 2038 problem
Older systems store the timestamp in a signed 32-bit integer, which can only count up to 2,147,483,647 seconds. That ceiling arrives on 19 January 2038, after which the number overflows and wraps around to a negative value, sending affected systems back to 1901. It is a real issue for legacy software, and the fix is to store the timestamp in a 64-bit integer, which pushes the limit far beyond any practical horizon. Most modern languages and databases already do this.
Reading and generating timestamps
To turn a timestamp into a date, or a date into a timestamp, paste it into the Unix timestamp converter. It auto-detects seconds versus milliseconds, shows the result in both UTC and your local time, and gives you the current timestamp with one click for testing. And like everything here, it runs in your browser, so the values you are debugging never leave your machine. If you are also wrangling the surrounding data, the JSON formatter pairs well for making an API response readable first.