Seconds or milliseconds, both readings shown, never guessed silently.
What it's for
Find out what date and time a long number in a log, database or app stands for — or get the number for a date you have.
Before you start
Have the number or the date to hand. A Unix timestamp counts the seconds, or sometimes milliseconds, since the start of 1970 in UTC, the world's reference time.
Enter the number or the date
Type or paste it into Timestamp or date. A date works too: write it as 2026-09-21, or with a time as 2026-09-21T14:30:00Z. Now fills in the current moment, and Epoch fills in 0, the starting point.
Say how to read the number
Leave Read the number as on Detect and the page decides from the number of digits. If you know which it is, choose Seconds or Milliseconds instead.
Pick the place
Show local time in is Manila to start with. Pick another city to see the wall-clock time there for the same moment.
Convert
Press Convert. The answer at the top also changes as you type.
Reading the result
If it goes wrong
A Unix timestamp is a count of seconds since 1 January 1970 UTC. That number is the same everywhere on earth at the same moment — a timestamp carries no timezone. The wall clock beside it is a rendering, which is why UTC is always shown too.
The real trap is seconds versus milliseconds. Unix time is seconds, but Date.now() and nearly every JavaScript API hand you milliseconds. Pass milliseconds where seconds are expected and you land in the year 57,000; pass seconds where milliseconds are expected and you get 20 January 1970 — which looks entirely plausible in a log.
Neither mistake throws. So this says which reading it used, and prints the other one beside it: that one lands in 1970 or in the year 33,658, which makes a wrong guess obvious at a glance.
By its size. A current timestamp in seconds is ten digits; the same instant in milliseconds is thirteen. Anything above 9,999,999,999 is read as milliseconds, which holds until the year 2286. The page tells you which reading it used and shows what the other one would have given, so a wrong guess is obvious rather than silent — the alternative will land in 1970 or in the year 33,658.
Because neither mistake throws an error. Unix time is seconds, but Date.now() and almost every JavaScript API hand you milliseconds. Feed milliseconds to something expecting seconds and you get a date around the year 57,000; feed seconds to something expecting milliseconds and you get 20 January 1970 — which looks almost plausible in a log. Expiry timestamps on tokens are the classic casualty.
No. It counts seconds since 1 January 1970 UTC and is the same number everywhere on earth at the same moment. The wall clock shown beside it is a rendering of that instant in one place — which is why UTC is always displayed too. If you are storing a moment, store the timestamp; the timezone is a display choice made later.
A signed 32-bit integer runs out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. A system still storing Unix time in 32 bits wraps around to 1901 at that point. The page flags any timestamp past it. If you are choosing a column type today, make it 64-bit.
Yes — type a date instead of a number. 2026-09-21 or 2026-09-21T14:30:00Z both work. A date with no offset is read as UTC, which is what JavaScript does; if you meant a local wall clock, add the offset (2026-09-21T08:00:00+08:00).
Not supported, deliberately. Postgres, Go and several tracing formats do use them, but a sixteen-digit number is genuinely ambiguous — it is also a valid millisecond value from the distant future — and guessing wrong is worse than declining. Divide by 1,000 or 1,000,000 first and the result is exact.
Important
Runs entirely in your browser; nothing is transmitted. A timestamp is an instant and carries no timezone — the local time shown is a rendering of it, and UTC is always shown beside it. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.
