Unix Timestamp Converter - Epoch to Date and Back

Unix time in one paragraph

Unix time counts seconds since the epoch: 00:00:00 UTC on Thursday, January 1, 1970. Zero is the epoch itself. 1,000,000,000 was 2001-09-09T01:46:40Z. 1767225600 is midnight UTC on January 1, 2026. Negative numbers are dates before 1970. The count has no time zone and no daylight saving, which is exactly why logs, databases, and APIs love it: one integer, one moment, everywhere on Earth.

One quirk: Unix time pretends leap seconds do not exist. Every day is exactly 86,400 seconds. For almost all software that is a feature, not a bug.

What the converter shows

Paste a number and you get five readings: your local date and time, the UTC time in ISO 8601 format (2026-01-01T00:00:00.000Z), a relative time like "3 hours ago" or "in 2 days", and the value in both seconds and milliseconds. The Now button fills in the current moment, handy for grabbing a fresh value to paste into a test or a config file.

To go the other way, pick a date and time in the date input. It is read in your local time zone and converted to Unix seconds. Anything that is not a number, like a stray letter or an empty paste, shows an error instead of a fake date.

Seconds or milliseconds: the auto-detect rule

Unix tools, PHP, Python's time.time(), and most databases use seconds. JavaScript does not: Date.now() and new Date(value) use milliseconds. Java's System.currentTimeMillis() does the same. Mixing the two up is the single most common timestamp bug.

This converter decides for you. Any value whose absolute size is 100,000,000,000 (1e11) or more is read as milliseconds; anything smaller is read as seconds. In practice that means 13-digit values are milliseconds and 10-digit values are seconds. The rule is safe because 1e11 seconds is the year 5138, while 1e11 milliseconds is March 3, 1973. The only values it can misread are millisecond timestamps from before March 1973, which rarely show up outside historical data.

Worked example: 1735689600 has 10 digits, so it is seconds: 2025-01-01T00:00:00Z. In Chicago that displays as 6:00 PM on December 31, 2024, because Central Time is 6 hours behind UTC in winter. Paste 1735689600123 instead and it is read as milliseconds: the same moment plus 123 ms.

The Year 2038 problem

Older C code and many embedded systems store Unix time in a signed 32-bit integer. The largest value that type can hold is 2,147,483,647, which is 2038-01-19T03:14:07Z. One second later the counter wraps to -2,147,483,648, which reads as 1901-12-13T20:45:52Z. Anything doing date math on that value, from certificate checks to scheduled jobs, breaks.

Modern 64-bit operating systems, databases, and languages already use 64-bit time, which is good for billions of years. The risk sits in old firmware, file formats, and database columns typed as 32-bit integers. MySQL's TIMESTAMP type, for example, tops out at 2038-01-19 03:14:07 UTC, which is why many schemas use DATETIME or BIGINT instead. If you are designing something today that must store dates past 2038, check the column type now.

Debugging with timestamps

Date lands in January 1970? You passed seconds to something expecting milliseconds. new Date(1735689600) in JavaScript gives January 21, 1970, because it treats the number as 1.7 million seconds' worth of milliseconds. Multiply by 1000.

Year is in the tens of thousands? The reverse: milliseconds were treated as seconds. Divide by 1000.

Off by exactly 4 to 8 hours? That is a time zone mix-up, not a units problem. Continental US offsets from UTC run from -5 (Eastern Standard) to -8 (Pacific Standard), one hour less in summer. Check whether your code parsed a date string without a Z or offset, which many parsers read as local time.

JWT exp and iat claims are Unix seconds, so this converter is the fastest way to see when a token expires. Paste the value and the relative time tells you if it is already dead.