The Unix Timestamp Converter turns the large 10-digit (or 13-digit) numbers that databases, APIs, and server logs use to store time — known as Unix epoch timestamps — into a date and time you can actually read. It also works the other way: pick any date and time and it returns the exact Unix timestamp that represents that moment, computed in your local time zone.

A Unix timestamp counts the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC (the "epoch"), ignoring leap seconds. It is the standard way almost all programming languages, databases such as MySQL and Postgres, and JSON APIs store a point in time, because a single number is compact, time-zone-free, and easy to compare. Developers, system administrators, and data analysts reach for a converter daily when they see a field like ts: 1697126400 and need to know what moment that actually was.

This tool accepts both seconds (10 digits) and milliseconds (13 digits) automatically, and correctly handles timestamps before the epoch as negative numbers. Because the conversion runs entirely in your browser, your dates never leave the page.

How Does the Conversion Work?

When you enter a number, the script first decides whether it is in seconds or milliseconds. Any value whose absolute magnitude is 1 quadrillion (1e15) or more is treated as milliseconds and divided by 1000; a value in the common 10–digit range is read as seconds directly; a 13–digit value is milliseconds and is divided by 1000. The resulting seconds offset from the epoch (1970-01-01 00:00:00 UTC) is turned into a real date by the browser's Date object, then rendered in UTC so that two people in different time zones reading the same timestamp see the same universal moment, just labelled with UTC.

Going the other way, the script reads your local date and time, converts it to a UTC moment, and computes the number of seconds (and milliseconds) since the epoch. This is the value that most systems expect — a single, time-zone-independent number.

Practical Examples

An API response that stores an event with ts: 1697126400 is always the same instant no matter where your server lives: October 12, 2023 at 16:00:00 UTC. If a database log records last_login: 1650000000000, that trailing three zeros reveal the value is in milliseconds, which the tool detects and divides by 1000 to give you April 15, 2022 at 09:40:00 UTC. And when you need to store "now" in a program, entering today's date into the second box returns the exact seconds value to save on the server.

Edge Cases and Common Pitfalls

The most frequent mistake is confusing seconds with milliseconds: a seconds timestamp grows by one per second, while a milliseconds timestamp grows by 1000 per second, so they look completely different in the last three digits. This tool detects the scale automatically, but if you are writing code, always confirm which unit your API returns. Another pitfall is timestamps before 1970: the epoch is a reference point, and dates earlier than 1970 are represented by negative numbers (for example, 1969-06-01 is -18489600), which the tool reads correctly. Finally, be aware of the year 2038 problem: timestamps stored in a signed 32-bit integer overflow in January 2038, which is why modern systems use 64-bit integers or milliseconds.

Timezone Notes

The date you see for a given timestamp is always shown in UTC, because that is the anchor the Unix epoch is defined against. When you convert a date and time back to a timestamp, the tool interprets your selection in your browser's local time zone and normalizes it to UTC automatically. This two-hop design means the result you get from a 10-digit timestamp will match what a developer in Tokyo or New York computes for the same number, even though their local clocks read differently.