Epoch to Date Converter
Paste a Unix timestamp and read the moment it means.
Runs entirely in your browser
Loading the tool…
Current Unix time: …
—
| Relative | — |
|---|---|
| Your local time | — |
| UTC | — |
| ISO 8601 | — |
| RFC 2822 | — |
| Readable | — |
| Seconds | — |
| Milliseconds | — |
| Day of year | — |
| ISO week | — |
| Leap year | — |
Paste the number and read the moment. This is the direction you want when a log line, a database column or an API response has handed you an integer where a date should be, and the question is simply what it says.
Seconds or milliseconds are detected rather than asked about, because the digit count gives it away: a ten-digit number is seconds and a thirteen digit one is milliseconds, and getting that backwards puts you in 1970 or in the year 56000. Both readings appear in the table below, so you can see which one was meant.
Every form of the same instant is listed at once: your local time, UTC, ISO 8601, RFC 2822, the day of the year and the ISO week. The two that usually matter are local and UTC, since a timestamp carries no timezone at all. It is a count of seconds from a fixed instant, and the timezone is added by whoever displays it, which is where most confusion about "wrong" timestamps actually comes from.
A negative number is valid and means before 1970. To go the other way, from a date to a number, use date to epoch.
How to use it
- Type or paste the value, which converts as you type.
- Read the headline answer, and the table below it for every other form.
- Press Use now for the current moment, or the other button to swap direction.
Questions
Is my timestamp in seconds or milliseconds?
Count the digits. Ten digits is seconds and covers dates around now; thirteen is milliseconds. Java, JavaScript and most JSON APIs hand out milliseconds, while Unix tools, Postgres and Go default to seconds. The page detects it, and shows both readings in the table so you can confirm which was intended.
Why does the date differ from what my database shows?
Because a timestamp has no timezone in it. It is a count from a fixed instant, and the date you see depends entirely on which zone renders it. Your database is probably displaying UTC while this page leads with your local time. Both rows are in the table, and they describe the same moment.
What is the 2038 problem?
A signed 32-bit timestamp runs out on 19 January 2038, when the count exceeds what the type can hold and wraps to a negative number, putting the date in 1901. Anything storing time in a 32-bit integer is affected. Modern systems use 64 bits and are fine for longer than the question will matter.
Can a timestamp be negative?
Yes, and it simply means before 1 January 1970. Dates of birth are the usual place to meet one. Some libraries reject negative timestamps or read them as unsigned and report a date far in the future, which is worth knowing when a birthday comes back as the year 2106.
Why does Unix time start in 1970?
Because that is when it was chosen, not because anything happened. The first Unix systems needed an origin close enough that a 32-bit count would cover a useful span, and 1 January 1970 was the round date nearest to hand. Everything since has kept it for compatibility rather than for meaning.
Is my data sent anywhere?
No. The conversion runs in WebAssembly in this tab and the page makes no request of its own, so a timestamp out of a production log stays where you pasted it. Disconnect first and everything on this page still works.
The other direction
The same converter, opened the other way round. The toggle on either page still switches between them.
Your data stays on your device
Everything above runs inside your browser as WebAssembly compiled from Rust. Nothing you type is uploaded, logged or stored on a server. You can load this page once, go offline, and it still works.
This page makes no requests at all, to anywhere. That is not a promise in the copy: it is a Content-Security-Policy header your browser enforces, and connect-src on it is none. Open the network tab and watch nothing happen.