Unix Timestamp Converter

Convert Unix epoch timestamps to and from human dates.

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds elapsed since the Unix epoch, 1970-01-01 00:00:00 UTC. It's the universal way computers store time, independent of time zones. This converter auto-detects whether you entered seconds or milliseconds (by length), shows the ISO 8601 / RFC 3339, RFC 2822, and local representations plus a relative “time ago” phrasing, renders the instant in any IANA timezone, and converts a calendar date back into a timestamp. Everything is computed in your browser.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Turning a timestamp from a log or a database column into a readable date while debugging.
Producing an epoch value for an API that expects one.
Checking whether a stored timestamp is in seconds or milliseconds.
Working out the exact instant an event occurred in a chosen time zone.
Comparing two timestamps that are written in different formats.

How it works in practice

A worked example

A nightly report disagrees with the dashboard by a handful of rows, and both of them are reading exactly the same stored timestamps.

Input

Timestamp:  1773973800

Output

UTC                  Friday, 20 March 2026 at 02:30:00 UTC
America/Los_Angeles  Thursday, 19 March 2026 at 19:30:00 GMT-7
America/New_York     Thursday, 19 March 2026 at 22:30:00 GMT-4
Asia/Kolkata         Friday, 20 March 2026 at 08:00:00 GMT+5:30
Asia/Tokyo           Friday, 20 March 2026 at 11:30:00 GMT+9
Australia/Sydney     Friday, 20 March 2026 at 13:30:00 GMT+11

One instant, six wall clocks, and two different calendar days. The number is unambiguous and knows nothing about anywhere, but the moment it is rendered the chosen zone decides which day it belongs to. That is precisely where two reports drift apart: this row lands on the twentieth if you group in UTC and on the nineteenth if you group in Los Angeles, and so does every event in the seven and a half hours before midnight. Nothing is wrong with either total, and they will never agree.

The edge case that catches people

Which makes a daily figure a choice rather than a fact. A day is a local construct and an epoch value has no locality, so a report has to name the zone it groups by before its numbers mean anything at all — and two systems that answer that question differently will disagree permanently, by exactly the volume that falls inside the offset window. Decide the zone deliberately, print it next to the total, and never let it default to whatever the reporting server happens to be configured with.

When not to use this tool

An epoch value is the wrong way to store something that has not happened yet. It pins an instant, and a future appointment is not an instant — it is a wall-clock time in a place, so if that place moves its offset before the date arrives, the number you saved now points at the wrong local time and nobody finds out until someone misses the meeting. Keep the civil time and the IANA zone name for anything scheduled, and resolve to an instant only when you need to sort or compare. These values are for recording what happened.

Frequently Asked Questions

What is a Unix timestamp?: Seconds elapsed since 1970-01-01 00:00:00 UTC, the epoch. It is always UTC and carries no timezone — which is exactly why it is used for storage, since the same instant has one unambiguous representation everywhere.
Seconds or milliseconds?: Unix is seconds; JavaScript's Date.now() returns MILLISECONDS. Mixing them is the most common bug here and is easy to spot: a 10-digit number is seconds (a date around now), a 13-digit one is milliseconds.
What is the Year 2038 problem?: A signed 32-bit timestamp overflows on 2038-01-19 at 03:14:07 UTC and wraps to 1901. Systems using 64-bit time are unaffected, but embedded devices and old database columns remain genuinely at risk.
Does it account for leap seconds?: No, and this is a deliberate design decision. Unix time assumes every day is exactly 86,400 seconds, so a leap second is absorbed by repeating or stretching a value rather than adding one — meaning it is not strictly a count of elapsed seconds.
How should I store timestamps?: As UTC, converting to local time only for display. Storing local time loses the offset and becomes ambiguous during daylight-saving transitions, where one wall-clock hour occurs twice.
Why do some timestamps have 13 digits and others 10?: Ten digits are seconds, thirteen are milliseconds — JavaScript's `Date.now()` returns the latter, most Unix tooling the former. Feeding one to code expecting the other lands you in 1970 or the year 54,000.
Are negative timestamps valid?: Yes, for dates before 1970, and plenty of code breaks on them. Birth dates and historical records routinely cross that boundary, which is where the assumption of a positive value fails.
Why store UTC rather than local time?: Because a local timestamp is ambiguous for one hour every autumn, when the same wall-clock time occurs twice. UTC has no such gap or repeat, which is why it is the only safe storage form.

Common errors and gotchas

Confusing seconds with milliseconds, which puts the date in 1970 or fifty thousand years out.
Forgetting epoch time is UTC, so displaying it in local time silently shifts it.
Assuming it counts every elapsed second. Leap seconds are not represented.
Using a 32-bit signed value, which overflows in 2038 and can wrap to a negative date.
Treating a negative timestamp as invalid, when it legitimately means a date before 1970.