Epoch Converter
Unix timestamp to date and back. Seconds or milliseconds detected for you, UTC and local time side by side.
About this tool
A Unix timestamp is just a count of seconds since 1 January 1970, UTC. That plainness is the point: it has no timezone, no calendar, no ambiguity about which number is the month, and comparing two moments is comparing two integers. Which is why databases, log files, APIs and JWTs are full of numbers like 1700000000 — and why you end up needing to turn one back into a date at the exact moment you are debugging something.
The one trap worth knowing is the unit. Some systems count seconds, others milliseconds, and the two look similar enough to be mixed up — the difference is a factor of 1000, which turns 2023 into either 1970 or a date far past the heat death of anything you care about. The unit is inferred from the size here and stated explicitly above the results, so you can see which reading you got rather than discovering it three steps later.
Results are shown as ISO 8601, readable UTC, your own local time with the zone named, and a relative phrase like "3 months ago" that answers the question you usually actually have. Converting back accepts ISO 8601 and other unambiguous formats, but deliberately refuses things like 03/04/2026, where the answer depends on which country wrote it. Everything runs in your browser — timestamps out of production logs never leave your machine.
Frequently asked questions
How does it know whether my number is seconds or milliseconds?
By size, and it tells you which it picked. Anything below 100,000,000,000 is read as seconds, anything above as milliseconds. The two ranges cannot collide: that threshold is the year 5138 in seconds but 1973 in milliseconds, so every real timestamp lands unambiguously on one side. Getting this wrong is the classic bug in date handling — a value off by a factor of 1000 turns 2023 into 1970 or into the year 55000, and it usually ships unnoticed.
Why will it not accept a date like 03/04/2026?
Because that date has two readings — 3 April in most of the world, 4 March in the United States — and guessing wrong produces a plausible answer that is silently a month off. Rather than pick a side, unambiguous formats are required. ISO 8601 always works: 2026-04-03, or 2026-04-03T22:13:20Z if you need the time.
Which timezone is the result in?
Both are shown. UTC is what the timestamp actually means — Unix time counts seconds since 1970 in UTC and carries no timezone of its own — and your local time is shown alongside, labelled with the zone your browser reports. When comparing a timestamp against a log entry or a screenshot, check which of the two you are reading; most of the confusion around timestamps comes from mixing them.
Can it handle dates before 1970?
Yes, they are negative. −86400 is 31 December 1969, one day before the epoch. Systems differ in how well they handle negative timestamps, so a value that works here may still break something downstream, but the conversion itself is well defined.
What is the 2038 problem?
Systems that store Unix time in a signed 32-bit integer run out of room at 2,147,483,647 seconds — 19 January 2038 — and wrap around to 1901. It is the same shape of bug as Y2K and it is still present in older embedded systems and some file formats. Anything using 64-bit time, which includes JavaScript, is unaffected for the next few hundred million years.
Is anything sent to a server?
No. The conversion is arithmetic done in this page, and no request is made while you work. Timestamps pulled out of logs and database rows stay on your machine.