Epoch converter

Working with Unix epoch time

A Unix timestamp is the cleanest way a computer can record a moment: a single integer counting the seconds since 00:00:00 UTC on 1 January 1970, the so-called epoch. Because that number carries no timezone and no formatting, it is unambiguous, easy to sort, and trivial to compare — which is why almost every database row, server log line and API response stores time this way. This converter turns those raw integers into dates you can read, and turns human dates back into timestamps, entirely inside your browser.

The catch is that a single instant looks different depending on the timezone you display it in. The timestamp 1774828800 is exactly one moment, but your screen will show it as one wall-clock time in London and another in New York. That is why the tool always shows both the UTC value and your local value: they describe the same instant, just rendered in different offsets.

A worked example

Paste 1774828800 with the unit set to seconds. The browser multiplies it by 1000 to get milliseconds, builds a Date, and reports Sat, 28 Mar 2026 00:00:00 GMT for UTC. If your machine is set to US Eastern time (UTC−4 in late March), the local row instead reads around 27 Mar 2026, 20:00 — five hours earlier on the clock, the very same instant in reality. Add three zeros to make it 1774828800000 and the auto-detector treats it as milliseconds, landing on the identical date.

Milestones on the epoch line

Seconds vs milliseconds

The biggest source of off-by-1000 bugs is mixing units. Unix tools, PostgreSQL and most log formats use seconds (a 10-digit number today). JavaScript’s Date.now(), Java and many JSON APIs use milliseconds (13 digits). When in doubt, count the digits: a present-day timestamp with ten digits is seconds; thirteen is milliseconds. Leave the unit on Auto-detect and the tool will make that call for you.