Unix Timestamp Converter

What Is a Unix Timestamp?

A Unix timestamp is a single integer counting the seconds that have elapsed since January 1, 1970, 00:00:00 UTC — an instant called the Unix epoch. Right now that number is around 1.7 billion; it crossed one billion in September 2001. The format is deliberately plain: no time zone, no calendar, no formatting — just a count of seconds. Because the epoch is fixed in UTC, the number represents the same instant for every system on Earth, which is precisely why it became the universal way for computers to agree on time. Almost every programming language, database, and API you will ever touch stores or transmits moments in this form, and converting the occasional raw timestamp back into a human calendar date is a routine developer chore.

Why Seconds Since 1970?

The choice of 1970 is pure history. The Unix operating system's designers needed a zero point for their internal clock in the early 1970s, picked the start of the previous year as something convenient, and the convention became a standard. What matters today is not the date's meaning but its ubiquity: JSON APIs emit it, PostgreSQL's default timestamp columns store it, JWT tokens embed it, file systems record it, and every logging framework timestamps events with it. Understanding the format means you can read the time right out of raw data instead of reaching for a tool.

The One Gotcha: Seconds vs Milliseconds

The most common mistake is confusing seconds with milliseconds. JavaScript's own Date.now() returns milliseconds, while most APIs and databases store seconds — so a value copied from browser code is often exactly 1000 times too large. The digit count tells you which you have: in the 2020s, seconds values are 10 digits and milliseconds values are 13. This tool expects seconds; if you paste a 13-digit value and the result lands in the 54,000s, you have milliseconds and should divide by 1000 first. A third variant exists too — some systems store minutes or days — but seconds and milliseconds cover the overwhelming majority of real data.

How the Tool Works

Type on either side and the other side updates instantly. The timestamp side accepts any whole number of seconds, including negatives for pre-1970 dates, and rejects fractions, letters, and out-of-range values with a clear message. The date side accepts ISO 8601 text: full strings like 2024-03-15T12:30:00.000Z, strings with a different offset such as 2024-03-15T12:30:00+02:00, or bare dates like 2024-03-15 (interpreted as UTC midnight). The converted date is always emitted in UTC with the Z suffix, so the value is unambiguous and identical everywhere on Earth.

Step-by-Step: Decoding a Raw Value

Suppose an API response contains "expires_at": 1710505800. Paste 1710505800 into the timestamp box. The tool multiplies by 1000 to get milliseconds, builds a date, and formats it in UTC: 2024-03-15T12:30:00.000Z — so the token expires at 12:30 UTC on March 15, 2024. Now do the reverse: type 2038-01-19T03:14:08.000Z and the tool answers 2147483648 — exactly one second past the 32-bit limit, a nice way to see the Y2038 boundary with your own eyes.

Reference Table

Paste any row into the tool to confirm — the round trip is exact in both directions.

Where Timestamps Turn Up

Once you start looking, raw seconds are everywhere — which is why every developer eventually needs a converter in their bookmarks. The common cases:

• APIs and tokens: JWT exp and iat claims, OAuth expiry, and most REST payloads carry seconds.
• Databases: default timestamp columns in PostgreSQL, MySQL, and SQLite store Unix seconds or milliseconds.
• Logs and events: server logs, analytics events, and metrics all stamp instants as numbers.
• File systems: file creation and modification times on most platforms are Unix-based.
• Cookies and sessions: expiration values in many languages are computed as timestamp arithmetic.

Reading Timestamps in the Wild

With practice you can read raw data the way you read a clock. A 10-digit number in a JSON payload or log line is almost certainly seconds: 1,500,000,000 means late 2017, and 1,700,000,000 means late 2023, so the leading digits alone date-stamp the value to within a few years. A 13-digit number is milliseconds — same values, times 1000 — which you will see in JavaScript timestamps and some NoSQL stores. A bare date like "2024-03-15" is not a timestamp at all but an ISO date, and a value with a trailing Z or an offset is already formatted. Being able to classify a value at a glance — seconds, milliseconds, or ISO — is the difference between fixing a broken log in seconds and burning an hour on it.

The Silent Zero

The timestamp 0 — January 1, 1970 — is worth special attention because many systems use it as a stand-in for "never" or "unknown": a missing password-change time, an unset expiry, a record imported from a legacy database with no date. When you decode a zero timestamp in your data, ask whether it means the epoch or means the value was never written — the two are indistinguishable from the number alone. The same applies to 1970-01-01T00:00:00Z showing up suspiciously often in reports; it is usually a placeholder, not a real moment in 1970.

Gotchas Beyond Seconds vs Milliseconds

Timezone Blindness Is a Feature

A timestamp is an instant, not a local date. Converting 1700000000 to "2023-11-14" is only correct for UTC viewers; in Tokyo it is already November 15. Always convert to a display zone at the last step of your pipeline, never earlier.

Leap Seconds Are Smoothed Over

Official UTC has inserted 27 leap seconds since 1972, but Unix time ignores them — it counts exactly 86,400 seconds per day. The result is that a timestamp can drift from true atomic time by under a minute, which is irrelevant for virtually every real use and universally accepted.

32-Bit Legacy Data

If you see timestamps near 2147483647 in old exports, they came from a 32-bit system — and anything claiming to be after 2038 in that format is corrupt.

Frequently Asked Questions