Unix Timestamp Converter

Convert timestamps to dates and back, with the unit detected for you

Runs entirely in your browser. Your data never leaves this device.

Enter a timestamp, an ISO date, or "now". One value per line; the unit is inferred from the digit count.
Input
Output

How to use it

  1. Paste a timestamp, an ISO date, or the word now. One value per line.
  2. Each value is shown in seconds, milliseconds, ISO 8601, UTC, your local zone, and as a relative time.
  3. The status bar reports which unit was assumed and which zone your browser is in.

Why the unit matters more than anything else

Unix time is a single number: seconds elapsed since 1 January 1970, 00:00:00 UTC. The trouble is that half the ecosystem counts in seconds and the other half in milliseconds, with microseconds appearing in tracing systems.

  • Seconds — 10 digits today. Unix APIs, JWT exp and iat claims, most databases, Go's Unix(), Python's time.time().
  • Milliseconds — 13 digits. JavaScript's Date.now(), Java's System.currentTimeMillis(), most JSON APIs written in either.
  • Microseconds — 16 digits. OpenTelemetry spans, some Postgres columns.

Get it wrong and the failure is loud but confusing. Milliseconds read as seconds lands you in the year 57,000. Seconds read as milliseconds lands you in mid-January 1970. Both are obviously wrong once you see the date, which is why this converter always prints the resulting date rather than just the converted number.

Time zones are a formatting concern, not a storage one

This is the single most useful mental model here: a Unix timestamp has no time zone. It is an instant. Two people on opposite sides of the world referring to the same moment write the same number.

Zones only appear when you render that instant for a human. 1755000000 is 2025-08-12T12:00:00Z in UTC, and something else on the wall clock in Istanbul or Los Angeles — same instant, different presentation. This tool shows both because the mismatch between them is where bugs live: a report that runs at "midnight" and produces different rows depending on which server generated it.

The practical rule that follows: store instants as UTC timestamps, convert at the edge, and keep the user's zone as a separate piece of data. Storing local time without an offset throws away information you cannot recover.

The 2038 problem, briefly

A signed 32-bit integer runs out at 2,147,483,647 seconds after the epoch — 03:14:07 UTC on 19 January 2038. One second later it wraps to negative and becomes December 1901.

Most modern systems use 64-bit time and are fine. What is not fine: embedded devices with long service lives, int database columns chosen years ago, file formats with a fixed 32-bit field, and protocols that specified one. The failures will be scattered and specific rather than systemic, which historically is the harder kind to find.

Leap seconds, and why Unix ignores them

Astronomical time drifts against atomic time, and leap seconds were the correction. Unix time does not model them: it asserts that every day contains exactly 86,400 seconds.

That simplification is what makes timestamp arithmetic trivial — add 86,400 and you have tomorrow — but it means Unix time is not a true count of elapsed SI seconds. During a leap second, systems either repeat a value or smear the adjustment across hours. For scheduling and display this is irrelevant. For measuring a precise interval that spans one, use a monotonic clock instead.

Frequently asked questions

How is the unit detected?

By digit count. Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds. It is a heuristic, not a guarantee — the status bar tells you what was assumed so you can spot a wrong guess.

Why does my timestamp show as 1970?

Almost always a unit mismatch: milliseconds interpreted as seconds gives a date near the epoch, and seconds interpreted as milliseconds gives one in January 1970. Check the digit count.

What is the year 2038 problem?

A signed 32-bit integer overflows on 19 January 2038, wrapping to 1901. Anything still storing time in a 32-bit int is affected — mostly embedded systems and old database columns. 64-bit timestamps push the limit past the lifetime of the sun.

Are Unix timestamps affected by time zones?

No. A Unix timestamp is always seconds since 1970-01-01 UTC. Time zones only enter when you format it for a human, which is why this tool shows UTC and your local zone side by side.

Do timestamps account for leap seconds?

No, and that is deliberate. Unix time pretends every day has exactly 86,400 seconds, so a leap second is either repeated or skipped depending on the system. This makes arithmetic simple and makes Unix time unsuitable for precise interval measurement across one.

Can I paste several values at once?

Yes — one per line. Each is converted independently, which is useful when reading a log file full of epoch values.

Related tools

browse category →
CRN Cron Expression Parser Explain a cron expression in plain English and list the next runs JWT JWT Decoder Decode and inspect JSON Web Tokens without sending them anywhere { } JSON Formatter Beautify, minify and validate JSON with the error position shown

Last updated: