Unix Timestamp Converter
Turn an epoch value into a readable date, or a date into an epoch. Seconds and milliseconds are both understood, in UTC and in your own time zone.
Paste a number or a date. “Now” fills in the current time.
| Unix seconds | — |
|---|---|
| Unix milliseconds | — |
| UTC (ISO 8601) | — |
| UTC (RFC 2822) | — |
| Your time zone | — |
| Your time zone (ISO) | — |
| Day of week | — |
| Relative | — |
About
A Unix timestamp is a count of seconds since midnight UTC on 1 January 1970, which is why it is also called epoch time. It carries no time zone and no calendar. It is a single number that means the same instant everywhere, and that is exactly why databases, APIs and log files prefer it. Everything else this page shows is that one number wearing a different set of clothes.
Paste a number and the converter decides whether it is seconds or milliseconds by size, because both are in daily use: PHP, MySQL and most command-line tools speak seconds, while JavaScript, Java and many JSON APIs hand out milliseconds. You can paste a readable date instead, either in ISO form such as 2026-11-05T06:30:00Z or something looser like 5 Nov 2026 17:30, and the page answers with both halves of the conversion at once.
The rows are the formats you actually meet in the wild. Unix seconds is what gets stored. Unix milliseconds is what a browser hands you. The ISO 8601 value in UTC is the interchange format, because it sorts alphabetically and leaves nobody guessing the zone. The RFC 2822 line is the same instant written the way an email Date header writes it. Your time zone and your time zone in ISO show the local rendering with the offset attached, which is what you need when something asks for a local time rather than UTC. Day of week is a quiet sanity check, and it earns its place: a fair share of "the schedule is off by one" reports turn out to be the wrong day of the week. Relative answers the question people usually ask first when reading a log, which is how long ago this happened.
One thing is worth holding on to. A timestamp is an instant, but a local time is an interpretation. The same number can be Thursday morning in Brisbane and Wednesday evening in Los Angeles, and in a zone with daylight saving the same wall-clock reading can occur twice in a year. The offset shown is the one in force at that moment, not the one in force today.
How to use
- Paste a timestamp, or type a date in almost any common form.
- Press Convert. The note underneath tells you which unit it assumed.
- Read the UTC rows first, then the offset form if you need to send a local time.
- Use Now to fill in the current epoch and see it in every format at once.
Frequently asked questions
What exactly is a Unix timestamp?
It is the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, not counting leap seconds. It is not a date in any calendar sense: it is a counter. Two machines in different countries holding the same number are agreeing on the same moment, which is the whole point.
Why does the count start in 1970?
Because that was a convenient round number when Unix was being written in the early 1970s, not because anything happened then. It also happened to fit inside a signed 32-bit integer for the next several decades, which made it cheap to store.
How does the tool know if my number is seconds or milliseconds?
By magnitude. Ten digits is seconds and thirteen is milliseconds, so anything below one hundred billion is read as seconds here and the note tells you which it chose. Numbers in between can genuinely be either, and only the system that produced the value can settle it.
Why does the converted date not match what I expected?
Almost always a time zone difference. The UTC rows show the instant as the rest of the world sees it, while the local rows apply your browser zone and its daylight saving rules for that date. Compare the two before deciding the conversion is wrong.
What is the difference between ISO 8601 and RFC 2822?
ISO 8601 is the 2026-11-05T06:30:00Z shape: sortable as plain text, unambiguous, and the default for APIs and filenames. RFC 2822 is the Thu, 05 Nov 2026 06:30:00 +0000 shape, which exists mainly because email headers were standardised long before ISO dates were common.
What is the year 2038 problem?
A signed 32-bit integer runs out of seconds at 03:14:07 UTC on 19 January 2038, and anything still storing timestamps that way wraps around to 1901. Most modern systems use 64-bit values and are fine, but embedded devices and older database columns are the usual culprits.
Are leap seconds counted?
No. Unix time deliberately ignores them, which keeps arithmetic simple but means the count drifts from astronomical time by roughly half a minute since 1972. For scheduling and logs this never matters; for astronomy it does, and those systems use a different scale.
Can a timestamp be negative?
Yes, for anything before 1970. They convert correctly here. Some systems store timestamps unsigned and cannot represent them at all, which is why a date that works in one database can fail in another.
What precision does the result have?
Milliseconds, because that is what JavaScript dates hold. A whole number of seconds converts exactly, and a fractional input is rounded to the nearest millisecond. Beyond about nine quadrillion milliseconds the floating point format itself starts losing precision.
Does this use my time zone, and is my input sent anywhere?
The local rows use the time zone your browser reports, including its daylight saving rules for that date. The conversion happens entirely in the page, so nothing you paste is uploaded or logged.
Where will I run into these numbers in practice?
Token expiry claims such as exp in a JWT, cache and session lifetimes, signed URL expiry, log line prefixes, database rows created with a timestamp column, and the touch times on files. Seeing one as a readable date is usually the fastest way to tell whether it has already expired.
Why does the relative time look wrong?
It compares the value against your device clock. If the computer or phone is a few minutes out, every relative time is out by the same amount, and a future timestamp can read as being in the past.