Epoch / Unix Timestamp Converter

Last reviewed on April 27, 2026.

The current Unix time, live, in three precisions, plus a converter that goes both ways between epoch numbers and human-readable dates. Times are computed locally; nothing is sent anywhere.

Now Live, updates every second

Precision	Value
Seconds	`—`
Milliseconds	`—`
Microseconds	`—`
ISO 8601 (UTC)	`—`

Epoch number Unit

Or pick a date Zone

Enter a number above, or pick a date.

All conversions are local.

What "epoch" means

Unix time counts seconds since 1970-01-01 00:00:00 UTC, ignoring leap seconds. That's it. The integer you see is the count: small means closer to 1970, large means further from it. Negative values represent dates before 1970, which is why a wrong configuration sometimes shows your file as modified in 1969.

Three precisions, three contexts

Unit	Length today	Where you find it
Seconds	10 digits	Most Unix command-line tools (`date +%s`), traditional file timestamps, many older APIs.
Milliseconds	13 digits	JavaScript's `Date.now()`, Java's `System.currentTimeMillis()`, most modern web APIs.
Microseconds	16 digits	Profiling tools, eBPF traces, some database internals (Postgres timestamps).

The "auto-detect" mode here looks at the magnitude: 10 digits is treated as seconds, 13 digits as milliseconds, 16 digits as microseconds. If your timestamp lives at a boundary (around the year 2001 in milliseconds, for example), pick the unit explicitly to remove the guess.

ISO 8601 — the format that does not lie

An ISO 8601 timestamp like 2026-04-27T14:32:05Z or 2026-04-27T16:32:05+02:00 tells you:

The exact date.
The exact time, to whatever precision you keep.
The timezone — either Z for UTC or an explicit offset.

That last part is the crucial one. A timestamp without a timezone is ambiguous, and the difference between "noon UTC" and "noon in Sydney" is 11 hours of confusion. Always store with timezone information, even if the timezone is just Z.

The Year 2038 problem, briefly

Unix timestamps stored in a signed 32-bit integer overflow at 03:14:07 UTC on January 19, 2038. Past that moment, the value wraps around to a large negative number, and any system still using signed 32-bit time will misbehave. Every modern operating system has moved to 64-bit time, which postpones the problem by roughly 290 billion years. The risk today is restricted to embedded systems and old protocols that have not been migrated. If you maintain firmware or a long-lived custom binary format, this is the year to audit it.

Worked example: debugging a "wrong" timestamp

Your monitoring system shows an event at 1746022325000 but your logs show 1746022325. Are these the same event?

The first number has 13 digits — milliseconds.
The second has 10 digits — seconds.
Divide the first by 1000: 1746022325. They match.

The "auto-detect" mode handles this for you. When two systems disagree by a factor of 1000, this is almost always the cause.

Common mistakes

Mixing precisions silently. Adding a second-precision timestamp to a millisecond-precision one without conversion gives a value about 50 years off. Always normalize first.
Storing local time as if it were UTC. A 2026-04-27 14:00:00 with no timezone is unanswerable: it could be 14:00 in any of 24 places. Either store the offset or store as UTC and convert on display.
Using seconds for sub-second events. A second is a long time on modern hardware. If your application logs more than one event per second, second-precision timestamps will produce duplicate keys and confused ordering. Move to milliseconds, or use a v7 UUID (see the UUID generator).
Trusting Date.parse() on non-ISO input. Browsers parse 2026-04-27 as UTC midnight, but 04/27/2026 as local midnight, and April 27 2026 is implementation-defined. Stick to ISO 8601 for any string you expect to round-trip.
Forgetting daylight saving. Most local-time arithmetic across DST boundaries goes wrong without explicit timezone handling. Store UTC, display local; never the other way around.

Where this fits with the other tools on the site

Generate a time-ordered identifier with the UUID generator in v7 mode, then check the timestamp embedded in it by decoding the first 48 bits. Pair with the JSON formatter when you are debugging an API payload that mixes Unix timestamps and ISO strings — both formats sort and compare cleanly once you have made them consistent.