What This Tool Does

A Unix timestamp is a single number representing a point in time — the count of seconds (or milliseconds) since a fixed reference moment. This tool converts a timestamp into a readable date in both UTC and your local timezone, and converts a date back into a timestamp, entirely in your browser.

How to Use It

To convert a timestamp to a date, choose a unit — Auto-detect works for almost any realistic value — enter the number, and click Convert to Date. To go the other way, type a date/time string (ISO 8601 is safest, e.g. 2023-11-14T22:13:20Z) into the second box and click Convert to Timestamp; both the seconds and milliseconds forms are shown together.

The Formula

Converting seconds to a date multiplies by 1000 (since JavaScript's Date object always works in milliseconds internally) and constructs a date from the result; milliseconds are used directly. Converting a date back to a timestamp reads Date.getTime() (milliseconds since the epoch) and divides by 1000 for the seconds form. Auto-detect uses a simple, widely-used magnitude heuristic: a value under roughly 10¹² is assumed to be seconds, and anything larger is assumed to be milliseconds, since real-world dates in either unit fall cleanly on either side of that line.

A Worked Example

The timestamp 1700000000 (seconds) converts to 2023-11-14T22:13:20.000Z in UTC. The same numeric value interpreted as milliseconds instead — 1700000000milliseconds after the epoch — is barely 20 days after January 1, 1970, a completely different and obviously wrong-looking date for anything meant to represent "now" in a modern system. That gap is exactly why getting seconds vs. milliseconds right matters.

Seconds vs. Milliseconds: The Most Common Timestamp Bug

The Unix epoch is a fixed reference point: January 1, 1970, 00:00:00 UTC. Traditionally, Unix timestamps count whole seconds since that moment. JavaScript's own Date object, however, works in milliseconds internally — new Date(timestamp)always expects milliseconds, and passing it a seconds-based timestamp without multiplying by 1000 first silently produces a valid but wildly wrong date, usually landing sometime in early 1970 instead of the intended date. This is a real, extremely common bug: an API that returns seconds fed straight into JavaScript's Dateconstructor, or the reverse — a millisecond value divided by 1000 unnecessarily — both produce a date that's off by a factor of 1000, which is easy to miss at a glance since the output still looks like a plausible date some of the time.

As a genuinely interesting piece of related context: many older systems store Unix timestamps as 32-bit signed integers, which can only represent seconds up to 2,147,483,647 — a moment that arrives on January 19, 2038. Past that point, a 32-bit signed timestamp overflows and wraps around to a large negative number, which typically gets interpreted as a date back in December 1901. This is widely known as the "Year 2038 problem," and while most modern systems have since moved to 64-bit timestamps (which won't overflow for billions of years), it remains a real concern for older embedded systems and legacy software still running 32-bit time representations.