What Is a Unix Timestamp and How Do You Convert It?

If you've worked with APIs, logs, or databases, you've probably seen a number like 1748390400 standing in for a date. That's a Unix timestamp, one of the most common ways computers store time. Here's what it means and how to convert it to something humans can read.

What a Unix timestamp actually is

A Unix timestamp is the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, a moment known as the Unix epoch. It's a single integer, which makes it compact, easy to sort, and simple to do math with, no time zones or month lengths to wrestle with inside the stored value.

Because it counts from a fixed point in UTC, the same timestamp refers to the exact same instant everywhere on Earth. What changes is how you display it in a given time zone.

Seconds vs. milliseconds

One frequent gotcha: not every system uses seconds.

• Seconds: The classic Unix convention. A 10-digit number today, like 1748390400.
• Milliseconds: Common in JavaScript (Date.now()) and many APIs. It's the same epoch but multiplied by 1000, giving a 13-digit number like 1748390400000.

If a converted date lands in 1970 or thousands of years in the future, you've almost certainly mixed up the two. Divide by 1000 to go from milliseconds to seconds, or multiply to go the other way.

UTC vs. local time

The timestamp itself is always anchored to UTC. When you convert it to a readable date, you choose which time zone to show it in:

• 1748390400 is 2025-05-28 00:00:00 UTC.
• That same instant is 2025-05-27 17:00:00 in Los Angeles (UTC-7 during daylight saving) and 2025-05-28 09:00:00 in Tokyo (UTC+9).

So the number never changes, only the human-friendly label you put on it. This is why storing timestamps in UTC and converting at display time avoids a lot of bugs.

The year-2038 problem

Many older systems store timestamps in a signed 32-bit integer, which can only hold values up to 2,147,483,647. That limit is reached at 03:14:07 UTC on January 19, 2038, after which a 32-bit counter overflows and wraps around to a negative number, jumping back to 1901. Modern systems use 64-bit integers, which push the limit billions of years out, but legacy code is still worth checking.

How to use it

The quickest way to read or generate these values is the Unix Timestamp Converter. Paste a timestamp to get a readable date, or pick a date to get the timestamp, with the live current epoch shown and support for both seconds and milliseconds.

For related work, the Date Difference Calculator helps when you need the human-readable span between two dates rather than raw epoch math. And since timestamps are just integers, the Number Base Converter is handy when you need to view one in hexadecimal or binary.

Quick reminders:

• Confirm whether your data is in seconds or milliseconds before converting.
• Store and compare in UTC; convert to local time only for display.
• Audit older systems for 32-bit timestamp limits.

Once it clicks that a timestamp is "seconds since 1970 in UTC," the rest is just formatting.