Unix Timestamp Converter

Paste a Unix timestamp to see it as UTC, as your local time, and as ISO 8601, or pick a date to get the timestamp back. It detects seconds, milliseconds and microseconds from the digit count rather than guessing, and shows which it used.

Why timestamps exist

A date written as text is ambiguous in ways that cause real bugs. Is 03/04/2026 the third of April or the fourth of March? What timezone was it recorded in? Did daylight saving apply? Sorting text dates alphabetically produces nonsense unless the format is exactly right.

A Unix timestamp sidesteps all of it. It is one integer counting seconds from a fixed moment, always in UTC. Comparing two of them is a numeric comparison, sorting is trivial, and there is no format to misread. That is why almost every log file, database and API uses them internally and converts to something readable only at the edge.

Seconds, milliseconds, and how this tool decides

The Unix definition is seconds, but many platforms use milliseconds — JavaScript'sDate.now() is the one most developers meet daily — and some use microseconds. Paste a millisecond value into a tool expecting seconds and you get a date about fifty thousand years in the future.

Many converters guess by magnitude: if the number is large, assume milliseconds. That breaks for genuine dates in the early 1970s, whose second-values are small. This tool counts digits instead — ten means seconds, thirteen means milliseconds, sixteen means microseconds — and tells you which reading it used, so a wrong guess is visible rather than silent.

The 2038 problem

Systems that store timestamps in a signed 32-bit integer can represent up to 2,147,483,647 seconds, which runs out at 03:14:07 UTC on 19 January 2038. One second later the value overflows into negative territory and the date reads as December 1901.

Most modern software moved to 64-bit values long ago and is fine for roughly the next 292 billion years. The risk sits in embedded systems, older databases and file formats that fixed the field width — which is why the date still appears on risk registers.

Reading them in context

Showing UTC and local time side by side is deliberate. A timestamp from a server log is UTC, but the incident you are investigating happened at a local wall-clock time, and reconciling the two is where mistakes creep in — particularly around a daylight-saving change, where an hour repeats or vanishes entirely.

The relative time is there for the most common check of all: is this recent, and roughly how recent. Nothing you paste is uploaded, which matters since timestamps usually arrive attached to production log lines.