Unix Timestamp Converter

What this does

Paste anything date-shaped — a Unix epoch number, an ISO 8601 string, or a date a human typed — and get every other representation of the same instant at once: Unix seconds, Unix milliseconds, ISO 8601 in UTC, a full UTC string, your local time, and how long ago or ahead that is. Seconds, milliseconds and the ISO form each have a copy button. Parsing happens in your browser, so log lines and tokens you paste never leave the machine and the page keeps working offline.

How do I convert a Unix timestamp?

Paste it in; every format is filled in at once:

1. Type or paste the number into the input. Results appear as you type — there is no button to press.
2. Press Now to load the current epoch in seconds, which is also what the page starts with.
3. Copy the row you need with the small copy button next to it.

How does it tell seconds from milliseconds?

By digit count. A whole number of fewer than 12 digits is read as seconds, which covers the entire epoch range people actually work with; 12 digits or more is read as milliseconds, the JavaScript and Java convention. A decimal such as 1715990400.123 is treated as fractional seconds. Microseconds and nanoseconds are not detected — divide by 1,000 or 1,000,000 yourself before pasting, or the value will be read as a date tens of thousands of years out.

What does it output for ISO 8601?

The ISO row is always UTC, in the canonical YYYY-MM-DDTHH:MM:SS.sssZ form with milliseconds and a trailing Z. That is the shape most APIs and databases expect, and it round-trips: paste it back in and you get the same instant. Input is more forgiving than output — an ISO string with a +05:30 or -04:00 offset is honoured, and a string with no zone at all is read in your browser's local zone.

Which timezone does the result show?

Two of them, deliberately. The UTC row is the absolute answer, and the Local row is the same instant formatted for whatever zone your browser reports, spelled out with the full date and the zone's name so there is no ambiguity about which offset was applied. The relative line ("3 hours ago", "2 months from now") is measured against your device clock, and uses approximate 30-day months and 365-day years, so treat it as a sanity check rather than an exact duration — for exact spans use date difference.

Does the 2038 problem affect this converter?

No. The 2038 problem is what happens to systems that store Unix time in a signed 32-bit integer: they run out of room at 03:14:07 UTC on 19 January 2038 and wrap to a negative number, landing in 1901. This page does the arithmetic in JavaScript, whose date type spans roughly ±273,000 years, so a timestamp past 2038 converts correctly here even when the system that produced it could not have stored it. Negative timestamps work too — they are simply dates before 1970.

What are the common uses?

Reading a created_at column out of a database dump, checking the exp and iat claims in a JWT (both are Unix seconds), lining up log lines from services that disagree about format, or working out which local time an event actually happened at — for which the timezone converter takes it the rest of the way.