Does it handle milliseconds as well as seconds?

Yes. The converter auto-detects the unit: a 10-digit value is treated as seconds and a 13-digit value as milliseconds, with microseconds and nanoseconds also recognised. You can see both the seconds and millisecond forms of any moment.

Is the conversion done on a server?

No. All conversion uses the browser's native Date object in your tab. Nothing is uploaded, and your local timezone is read from the browser, never sent anywhere.

What is the year 2038 problem?

Systems that store Unix time in a signed 32-bit integer overflow on 19 January 2038, when the second count exceeds 2,147,483,647. Modern systems use 64-bit timestamps, which push the limit roughly 292 billion years into the future.

Unix Timestamp Converter (Epoch ⇄ Date) — Local

Q: What is a Unix timestamp?

A Unix timestamp (or epoch time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It is a compact, timezone-independent way to store a moment in time, used throughout databases, APIs and log files.

On this page

How to use it
What a Unix timestamp is
Seconds, milliseconds & beyond
UTC vs local time
The year 2038 problem
FAQ

How to convert timestamps

The tool works in both directions at once. Paste a number into the left box and it is read as a Unix timestamp and expanded into a full set of readable forms — UTC, your local time, ISO 8601 and a relative "x ago" description. Type or paste a date into the right box — almost any common format works, from 2025-01-01 00:00:00 to 1 Jan 2025 UTC — and it is converted back to epoch seconds and milliseconds. Press Use current time to drop the present moment into both boxes, and use the per-line copy buttons to grab any value. The header clock ticks live so you always have the current epoch to hand.

What is a Unix timestamp?

A Unix timestamp, also called epoch time or POSIX time, is the number of seconds elapsed since the Unix epoch: midnight UTC on 1 January 1970. Because it is a single integer with no timezone attached, it is the most portable way to record an instant — every system agrees on what 1735689600 means regardless of where the server sits or what locale the user has. That is why timestamps are everywhere: database created_at columns, JWT iat/exp claims, HTTP caching headers, log lines and API responses. Converting one to a date you can read, and a date back to one a machine can store, is one of the most common small tasks in development.

Seconds, milliseconds and beyond

The classic Unix timestamp counts seconds and is ten digits for any date in the current era. Many languages and APIs — JavaScript's Date.now() chief among them — count milliseconds instead, giving a thirteen-digit number. Some systems go further to microseconds (16 digits) or nanoseconds (19 digits). This converter looks at the magnitude of your input and picks the right unit automatically, then shows you both the seconds and milliseconds form so there is never any ambiguity about which one a downstream system expects. If you paste a value with a decimal point, the fractional seconds are preserved.

UTC versus your local time

A timestamp itself has no timezone — it is an absolute count from the UTC epoch. The confusion always comes when you display it. This tool shows both: the canonical UTC rendering and the same instant in your local timezone, as read from your browser, with the UTC offset labelled. When you convert a date to a timestamp, the tool is explicit about whether it interpreted your input as local or UTC, so you do not accidentally shift a value by several hours. ISO 8601 output (for example 2025-01-01T00:00:00.000Z) is included because it is the format most APIs and databases prefer for storing dates as text.

The year 2038 problem

Older software stored Unix time in a signed 32-bit integer, which can only count up to 2,147,483,647 seconds — a ceiling reached at 03:14:07 UTC on 19 January 2038. One second later the counter overflows to a large negative number, throwing affected systems back to December 1901. The fix is to store time in a 64-bit integer, which moves the limit about 292 billion years away; most modern platforms have already made the switch. It is the same family of bug as Y2K, and a good reason to be deliberate about the integer width you use when persisting timestamps. None of this affects the conversions here, which use the browser's full-range Date object.

Both directions — epoch to date and date to epoch, side by side.
Auto unit detection for seconds, milliseconds and finer.
UTC and local output, plus ISO 8601 and relative time.
Live clock with the current timestamp always visible.
Local — uses your browser's clock and timezone, nothing uploaded.

Frequently asked questions

What is a Unix timestamp?: The number of seconds since midnight UTC on 1 January 1970 — a portable, timezone-free way to store an instant.
Does it handle milliseconds?: Yes. It auto-detects seconds (10 digits) vs milliseconds (13 digits) and shows both forms.
Is the conversion done on a server?: No. It uses the browser's native Date object locally; your timezone is read from the browser, never sent.
What is the year 2038 problem?: Signed 32-bit timestamps overflow on 19 Jan 2038; 64-bit storage fixes it for the foreseeable future.

Unix Timestamp Converter