Epoch Converter: Unix Timestamp to Date and Back

About this epoch converter

This epoch converter turns a Unix timestamp into a readable date and a date back into a timestamp. A Unix timestamp counts seconds from 00:00:00 UTC on January 1, 1970 and has no time zone of its own, so the converter shows each instant twice: in UTC and in your device's time zone.

How to use the Unix timestamp converter

1. Paste a timestamp into the first box. Spaces and underscores are ignored, a leading minus sign is allowed, and so is a decimal point.
2. Check the unit line under the box. If the converter guessed wrong, pick the unit from the menu.
3. Copy the format you need from the results: ISO 8601 for APIs and logs, RFC 2822 for email and HTTP-style headers, or the plain number in another unit.
4. To go the other way, pick a date and time in the second box and choose whether it means your local time or UTC.

How the converter reads your number

With the unit on auto-detect, the converter counts the digits before any decimal point, ignoring the sign and leading zeros:

For any date from September 2001 to November 2286, seconds have exactly 10 digits, milliseconds 13, microseconds 16 and nanoseconds 19, so the guess is reliable there. Outside that window, such as a millisecond value from the 1970s, the digit count can mislead, and the status line says so whenever the count is not 10, 13, 16 or 19. Choosing a unit from the menu overrides the guess.

The number is converted to nanoseconds with whole-number (BigInt) arithmetic, so a 19-digit nanosecond value keeps every digit in the ISO 8601 output and the unit rows. Only the local, readable line and the relative time are limited to milliseconds. Negative values are rounded toward the past, not toward zero, so -1.5 seconds is 1969-12-31T23:59:58.500Z.

Worked example

The converter opens on 1767225600. It has 10 digits, so it is read as seconds, and the results show:

UTC, ISO 8601     2026-01-01T00:00:00Z
UTC, RFC 2822     Thu, 01 Jan 2026 00:00:00 +0000
Milliseconds      1767225600000

On a device set to US Eastern time, the local lines read 2025-12-31T19:00:00-05:00 and Wed, 31 Dec 2025 19:00:00 -0500: the same instant, still on New Year's Eve in New York. The relative line depends on today's date. Viewed on October 17, 2026, it reads "9 months ago".

The date box below opens on the same instant written in your local time, so its seconds box shows 1767225600 wherever you are. Switch it to UTC and enter January 1, 2026, 00:00:00 to get the same number.

Converting a date to a timestamp

In local mode, the date you pick is read in your device's time zone. Daylight saving time makes two cases tricky. When clocks spring forward, some local times never happen: in New York, 2:30 AM on March 8, 2026 does not exist. When clocks fall back, an hour happens twice: 1:30 AM on November 1, 2026 occurs once in EDT and again in EST. The converter follows JavaScript's rule, described on MDN's Date reference: a missing time moves forward by the gap, so 2:30 AM becomes 3:30 AM EDT (1772955000), and a repeated time uses the earlier occurrence (1793511000). It tells you when either happens and shows the second occurrence (1793514600), which is one hour later. UTC mode has no such gaps, which is why servers usually schedule in UTC.

Output formats

• ISO 8601 lines use the internet profile in RFC 3339: Z for UTC, or an offset such as -05:00. Millisecond, microsecond and nanosecond input shows 3, 6 or 9 decimal places.
• RFC 2822 is the email date format, now defined in RFC 5322, section 3.3, with +0000 for UTC. That standard only allows years from 1900 on, so earlier dates show no RFC 2822 line.
• Relative time rounds down to whole units. Months are 30.436875 days and years 365.2425 days on average, so treat "9 months ago" as approximate.

Edge cases and limits

• Negative timestamps count back from 1970: -86400 is 1969-12-31T00:00:00Z.
• The 2038 limit. Values above 2147483647 (2038-01-19 03:14:07 UTC) or below -2147483648 (1901-12-13 20:45:52 UTC) don't fit a signed 32-bit integer. The converter flags them, because a 32-bit database column or embedded system would overflow. The Unix timestamp guide covers why.
• Range. JavaScript dates reach ±8,640,000,000,000,000 milliseconds, from April 20, 271821 BC to September 13, 275760 AD, according to MDN. Values outside that show as out of range.
• Historical local offsets. Before time zones were standardized, your browser may report a local mean time offset such as -04:56:02 for New York, which the local ISO line shows in full.

Common mistakes

• Passing seconds where milliseconds are expected. new Date(1767225600) in JavaScript gives January 21, 1970, because the constructor expects milliseconds.
• Reading the local line as UTC. A log stamped in UTC can be a day ahead of your calendar, as the worked example shows.
• Rounding negative values toward zero. Integer division in some languages turns -1500 ms into -1 s, which is half a second too late.

To read the exp and iat claims in a token, paste it into the JWT Decoder. To see a date in several cities at once, use the Time Zone Converter, and for the gap between two dates, the Date Calculator.

Unix timestamp reference table

Notable timestamps and the start of each calendar year in UTC. Add 000 to any value for milliseconds.

Each day adds 86,400 seconds, so a year adds 31,536,000, or 31,622,400 in a leap year such as 2024.

Related reading: Unix timestamp explained: epoch time and why 1970, UTC vs GMT: what's the difference?