Unix Timestamp Converter

Epoch time, both directions

Paste a Unix timestamp and get a date you can read. Paste an ISO date and get the timestamp. Leave the field empty and the tool shows the current moment, ticking, in every unit at once.

Everything runs in your browser — useful when the timestamp came out of a log you would rather not paste into someone else’s server.

What a Unix timestamp is

A count of seconds since midnight UTC on 1 January 1970. That instant is called the epoch, and the number is sometimes called epoch time or POSIX time.

The important property is what it does not carry: no time zone, no daylight saving, no calendar. 1785067200 names one instant, and it names the same instant in Tokyo as in Chicago. Only when you display it does a zone get involved.

That is why systems store it. A local time like “2 March, 01:30” is ambiguous twice a year and meaningless without a zone; a timestamp is neither. Sort a database by timestamp and the order is right regardless of where the rows came from.

Seconds, milliseconds, or something else

The one genuinely hard part of reading a timestamp is that the number does not say what unit it is in.

Roughly, for the present day:

Seconds — about 1.8 billion. Unix tools, most APIs, JWT claims, database UNIX_TIMESTAMP().
Milliseconds — about 1.8 trillion. JavaScript’s Date.now(), Java’s currentTimeMillis(), most browser and mobile telemetry.
Microseconds — Postgres internal timestamps, some tracing systems.
Nanoseconds — Go’s UnixNano(), Prometheus, high-resolution tracing.

Each is a thousand times the last, so the readings are three orders of magnitude apart and a wrong guess is never subtle. Read a millisecond value as seconds and you land tens of thousands of years in the future; read a seconds value as milliseconds and you land in January 1970.

The tool guesses from magnitude and tells you what it guessed, with a picker to override it. The bands are chosen by date rather than by round numbers, so that no value is a plausible date in two units at once — which is the property that makes guessing safe at all. A misread shows up as an absurd year, not as a wrong date you might believe.

Truncation, not rounding

Converting a millisecond value down to seconds throws away the fraction, and it throws it away by truncating.

So 15:20:00.860 becomes the second that began at 15:20:00, not the one that has not started yet. This matches every system that produces Unix time — C’s time(), Python’s int(time.time()), date +%s — and it means the seconds value the tool hands you never names a moment later than the one it is displaying.

Rounding would be tidier and wrong: nearly half of all conversions would come back one second in the future.

The year 2038 problem

A signed 32-bit integer can hold up to 2,147,483,647. As a Unix timestamp that is:

19 January 2038, 03:14:07 UTC.

One second later it overflows to the most negative value it can hold, which reads as December 1901. This is the same shape of problem as Y2K, and it has the same fix — use a wider type — but a harder deployment, because 32-bit time is baked into embedded devices, filesystems and network protocols that are not easy to update.

Most current systems already use 64-bit time and are fine for about 292 billion years. The ones that are not tend to be found the hard way, usually by a certificate or a scheduling calculation that reaches past 2038 and comes back nonsense. If you maintain anything long-lived, it is worth trying a date beyond the boundary and seeing what happens.

Leap seconds are not in there

Unix time is defined as though every day has exactly 86,400 seconds. The Earth’s rotation is not that obliging, so occasionally a leap second is inserted into UTC to keep clocks aligned with it.

Unix time handles this by pretending it did not happen — the same timestamp value is repeated, or the count simply carries on. Twenty-seven leap seconds have been added since 1972, so Unix time is now roughly half a minute behind the number of seconds that have actually elapsed since the epoch.

This almost never matters, and occasionally matters a great deal: a repeated second has broken production systems that assumed timestamps only ever increase. If you need a monotonically increasing clock, a wall clock of any kind is the wrong tool.

Which date formats are accepted

Numbers in any of the four units, and ISO 8601 dates — 2026-07-26, 2026-07-26T12:00:00Z, 2026-07-26T08:00:00-04:00.

Formats like July 26 2026 or 26/07/2026 are refused, which is deliberate rather than lazy. Browsers disagree about how to read them, some interpret them in your local zone and some in UTC, and 03/04/2026 is March in the United States and April nearly everywhere else. A converter that guessed would give two visitors two different answers from the same input, and neither would know.

Spaces, underscores and commas inside a number are stripped, because log formats add them and they never mean anything.

Reading the output

The tool shows the same instant several ways at once:

ISO 8601 (UTC) — the machine-readable form, safe to paste into anything.
UTC — the same moment written out, for reading.
Your zone — with the offset in force on that date, which is not always the offset in force today.
All four units — for pasting back into whatever system you got it from.

The relative label (“3 hours ago”, “in 2 days”) comes from your browser’s own language settings, so it says “yesterday” rather than “1 day ago” where that reads better.

To work with the same moment across several places at once, use the time zone converter.

Frequently asked questions

What is a Unix timestamp?

The number of seconds since midnight UTC on 1 January 1970. It has no time zone of its own — the same number names the same instant everywhere on Earth, which is exactly why systems store it instead of a local time.

Is my timestamp in seconds or milliseconds?

The tool guesses from how big the number is, and shows you the guess. A present-day value is about 1.8 billion in seconds and 1.8 trillion in milliseconds, so the two readings are a thousand times apart and cannot be confused. Use the picker to override it.

How do I get the current Unix timestamp?

With the field empty the tool shows the current moment, ticking once a second, in all four units. The Use the current time button freezes it so you can copy it.

Why does the seconds value not match my millisecond one exactly?

Converting down to seconds truncates rather than rounds, which is what every system that produces Unix time does — C's time(), Python's int(time.time()), date +%s. Rounding would give a second that has not started yet.

What is the year 2038 problem?

A signed 32-bit integer runs out at 2,147,483,647, which as a Unix timestamp is 19 January 2038 at 03:14:07 UTC. Systems still storing time that way will wrap to 1901. Most modern software uses 64-bit time and is unaffected, but embedded and legacy systems are still being found and fixed.

Does Unix time include leap seconds?

No. It is defined as if every day has exactly 86,400 seconds, so it silently repeats or skips a value when a leap second is inserted. Twenty-seven have been added since 1972, which means Unix time is now about half a minute behind the actual count of elapsed seconds.

Why does it refuse dates like "July 26 2026"?

Because browsers disagree about what they mean, and some read them in your local zone rather than UTC. The same input would give two visitors two different answers. ISO 8601 — 2026-07-26T12:00:00Z — is unambiguous and is accepted.