Unix Timestamp Converter

Convert a Unix timestamp to a readable date, or a date to a timestamp.

Runs 100% in your browser. Nothing you paste here is ever sent to a server. Don't take our word for it — open your browser's DevTools (F12) → Network tab, use the tool, and watch: no new requests fire. Why that matters.
Current Unix Timestamp

How this timestamp converter works

Enter a Unix timestamp (seconds since January 1, 1970 UTC) or a human-readable date, and it converts between them instantly using your browser's built-in Date object — no server round-trip needed.

Seconds vs. milliseconds — the most common bug

Unix timestamps are conventionally in seconds, but JavaScript's Date object and many APIs (including JavaScript's own Date.now()) use milliseconds. Pasting a seconds-based timestamp into a tool expecting milliseconds (or vice versa) produces a date off by a factor of 1000 — usually landing somewhere in 1970 or far in the future. If your converted date looks obviously wrong, check whether the timestamp you have is actually in seconds or milliseconds.

Timezones and the Year 2038 problem

The underlying epoch is always UTC, but the human-readable display typically converts to your browser's local timezone unless the tool explicitly shows UTC — worth double-checking if you're coordinating across timezones. Separately, systems that store timestamps as a signed 32-bit integer will overflow on January 19, 2038 (the "Year 2038 problem"), similar in spirit to Y2K; most modern systems have moved to 64-bit timestamps, but older embedded or legacy systems may not have.

Frequently asked questions

Why is my converted date wildly wrong?

The most common cause is a seconds-vs-milliseconds mismatch. Unix timestamps are conventionally in seconds; JavaScript Date objects use milliseconds. Multiply or divide by 1000 depending on which direction you're converting.

What timezone is the human-readable date shown in?

Typically your browser's local timezone, unless the tool has a UTC toggle. The underlying timestamp itself is always timezone-independent (UTC).

What is the Year 2038 problem?

Systems storing Unix time as a signed 32-bit integer will overflow on January 19, 2038, wrapping to a negative number. It mainly affects older or embedded systems that haven't moved to 64-bit timestamps.

Other tools