MinifyPic

Timestamp Converter

Turn a Unix epoch timestamp into a readable date, and any date back into a timestamp — in seconds or milliseconds, local or UTC.

FreeBoth directionsUTC & local
Loading tool…

How it works

A compact workflow from input to download.

1

Enter a timestamp or a date

Paste an epoch number to decode it, or pick a date to get its timestamp.

2

Read both views

The result is shown in both your local time zone and UTC, so there is no ambiguity about which one you are looking at.

3

Copy what you need

Copy the timestamp or the formatted date.

Frequently asked questions

What is a Unix timestamp?
The number of seconds that have elapsed since midnight UTC on 1 January 1970, a moment known as the Unix epoch. It is a single integer with no time zone, no calendar and no formatting, which is exactly why computers like it — it is unambiguous and trivial to compare and sort.
Is my timestamp in seconds or milliseconds?
Count the digits. A ten-digit number is seconds, which is the classic Unix convention. A thirteen-digit number is milliseconds, which is what JavaScript uses. Mixing them up produces dates in 1970 or dates fifty thousand years in the future, and it is one of the most common bugs in date handling.
Why do timestamps ignore time zones?
Because that is the point. A timestamp identifies an absolute instant, the same moment everywhere on earth. Time zones are a presentation concern applied when you display it to a human. Storing timestamps and formatting on display is the discipline that avoids an enormous class of date bugs.
What is the year 2038 problem?
Systems that store the timestamp in a signed 32-bit integer will overflow on 19 January 2038, wrapping around to a negative number and jumping back to 1901. It is the same shape of problem as Y2K. Modern systems use 64-bit timestamps, which push the overflow roughly 292 billion years into the future, but old embedded devices and legacy code remain genuinely at risk.
Is my data sent to a server?
No. Everything runs in JavaScript inside your own browser tab — nothing is uploaded, logged or stored. That is what makes it safe to paste in API responses, config files, tokens and other material you could not send to a third-party service.

One number, no ambiguity

Human dates are a mess to compute with. Is 03/04/2024 the third of April or the fourth of March? Which time zone was that recorded in, and was daylight saving in effect? How many days lie between two dates when one falls in a leap year? Every one of those questions has bitten a working programmer. A Unix timestamp dissolves all of them by reducing time to a single integer counting seconds from a fixed instant. Comparing two moments becomes comparing two numbers. Finding the interval between them becomes subtraction. Sorting is just sorting. All the horrors of calendars, locales and time zones are pushed to the edges of the system, where a date is parsed on the way in and formatted on the way out, and the messy middle is spared entirely.

Store in UTC, display in local

This is the single most valuable rule in date handling, and violating it causes a remarkable amount of pain. Store every instant as a UTC timestamp, and convert to the user's local time zone only at the moment you display it. The alternative — storing local times — means your data is full of moments whose meaning depends on where the person who created them happened to be sitting, and on whether daylight saving had shifted since. It produces the classic bugs: events that occur twice or never during a daylight-saving transition, reports whose totals depend on the server's location, and records that quietly shift by an hour twice a year. Timestamp in, format out, and the whole category of problem simply does not arise.