Timestamp Converter

Logs, databases and APIs rarely store dates the way people write them – they store a single number: the seconds (or milliseconds) since one fixed starting point. That number is a Unix timestamp, and converting it to a readable date, or back again, is one of the most frequent small annoyances in everyday programming. This converter does both instantly: paste a timestamp to get the date in local time, UTC, ISO 8601 and relative time, or pick a date to get the timestamp back in seconds and milliseconds.

How to use the Unix Timestamp Converter

1. Read the current epoch value from the Current Unix time panel at the top. It updates every second, and the Copy button beside it puts the value on your clipboard.

   

2. To convert a timestamp to a date: paste the number into the Unix timestamp → date box. The tool works out from the digit count whether it is seconds or milliseconds, then shows the result in local time, UTC, ISO 8601 (for example 2025-07-03T00:00:00.000Z) and relative time (“last year”).

   

3. To convert a date to a timestamp: pick a date and time in the Date → Unix timestamp box. The tool returns the Unix timestamp in both seconds and milliseconds.

   

4. Use the Copy button beside the Current Unix time, Seconds or Milliseconds field to copy that value straight to your clipboard.

   

What is a Unix timestamp, exactly?

A Unix timestamp, or epoch time or POSIX time, is the number of seconds that have passed since a fixed-point in time: January 1, 1970, 00:00:00 UTC, also known as the Unix epoch. It’s small and simple to understand, which is why it’s so common in databases, log files and APIs – it’s so much easier to store, sort and compare a single number than it is to store, sort and compare a date string.

It is also common to mix up seconds and milliseconds. A standard Unix timestamp is a 10-digit number – the seconds since the Unix epoch – and is used by PHP, MySQL and C. Many modern systems (JavaScript’s and Java’s Date.now(), and most newer APIs) use millisecond precision, giving a 13-digit number such as 1700000000000. Passing a milliseconds value to something expecting seconds, or the reverse, is one of the most common timestamp bugs and throws the date out by decades. This tool works out which one you have entered from the number of digits, so you never have to tell it.

A timestamp carries no timezone, and that catches people out. A Unix timestamp is one fixed, absolute moment – the same instant everywhere in the world. Only the way that instant is displayed depends on a timezone. That is why the UTC row and the local time row on this page can read differently while describing the very same moment: two representations of one instant, not two different times.

One real edge case is the Year 2038 problem. Some systems store Unix time in a signed 32-bit integer, whose maximum value is reached on 19 January 2038; past that the value overflows and wraps around to an incorrect date. Modern 64-bit systems are unaffected, but the limit still matters for older or embedded systems that keep 32-bit time storage.

When you’d use this

A log file or database record often carries nothing but a raw timestamp – paste it here to get a readable date for a report or a UI, and do the same with any timestamp field an API hands back. Working the other way, convert a date to an epoch value when you need to schedule an action against a Unix timestamp rather than a formatted date string, or when a script, API or database query expects a specific date as a number. And before you hard-code an epoch value anywhere, check here which date and time it actually points at.

Dos and Don’ts

Do

1. If a converted date is obviously wrong – out by decades – count the digits first; it is almost always a seconds/milliseconds mix-up.
2. When you are comparing timestamps from different systems or timezones, compare the UTC values – they are the only ones that cannot drift.
3. Copy the ISO 8601 value when you need a standardised, human-readable date string for logs, APIs or documentation.

Don’t

1. Don’t assume a timestamp belongs to a particular timezone – only the way it is displayed does.
2. Don’t expect epoch time to account for leap seconds; by design it does not.
3. Don’t ignore the 2038 limit on older 32-bit systems if you work with legacy hardware or embedded devices with long service lives.

Good to know

In practice these are all the same thing: epoch time, Unix time, Unix timestamp and POSIX time. If you have seen the terms used interchangeably, that is because in almost every computing context they are interchangeable. The most common practical mistake is still the seconds/milliseconds mix-up – 10 digits is seconds, 13 digits is milliseconds, and getting it the wrong way round moves the date by a factor of 1,000, which usually shows up as a date in the 1970s or somewhere far in the future. The Year 2038 problem, a signed 32-bit integer overflow, does not affect most modern systems but is still a genuine limit on older and embedded ones. Everything on this page is worked out locally by your browser and is never sent anywhere or stored.

FAQ: Unix Timestamp Converter Questions