Unix Timestamp Converter
Turn a Unix timestamp (epoch) into a readable date — in your local time, UTC, and ISO 8601 — or convert any date back into a timestamp. Works in seconds or milliseconds.
—
Milliseconds: —
ISO 8601: —
Paste an epoch value. Use the toggle if your timestamp is in milliseconds.
Pick a date and time to get its Unix timestamp.
How to use Unix Timestamp Converter
- 1
Enter a timestamp
Paste or type a Unix timestamp into the “Timestamp to date” field, and switch the Seconds / Milliseconds toggle to match your value.
- 2
Read the date
See the moment in your local time zone, in UTC, as an ISO 8601 string, and as a relative time such as “3 hours ago.”
- 3
Convert a date back
Use the “Date to timestamp” picker to choose any date and time and get its epoch value in seconds and milliseconds.
- 4
Copy the result
Click copy on any value to put it on your clipboard, ready to drop into code, a database query, or an API request.
Unix Time, Explained for Developers
What a Unix timestamp is
A Unix timestamp is a single number that represents a moment in time: the count of seconds that have elapsed since the Unix epoch, which is midnight UTC on January 1, 1970. The timestamp 1700000000, for example, corresponds to 22:13:20 UTC on November 14, 2023. One number captures the full date and time with no ambiguity.
Because it is just an integer counting upward, Unix time is trivial to store, sort, and compare. Subtract one timestamp from another and you get the exact number of seconds between two events. This simplicity is why it underpins so much of computing, from file modification times to authentication tokens.
Why 1970
The 1970 epoch is a historical artifact of the Unix operating system, which was being developed at Bell Labs around that time. The engineers needed a fixed reference point for the system clock, and the start of the decade they were working in was a clean, convenient choice. It stuck, and decades later it remains the standard across virtually every platform.
There is nothing mathematically special about 1970; it is simply a shared zero point. What matters is that everyone agrees on it. That common reference is what lets a timestamp generated on one machine be understood correctly by any other, regardless of vendor, language, or location.
Seconds versus milliseconds
Traditional Unix time is measured in seconds, but many modern environments use milliseconds for finer resolution. JavaScript's Date.now, for instance, returns milliseconds. The practical tell is digit count: a current timestamp in seconds is 10 digits, while the same moment in milliseconds is 13 digits, roughly a thousand times larger.
Mixing the two units is a frequent bug. Feed a millisecond value into a function expecting seconds and your date lands tens of thousands of years in the future; do the reverse and you land back near 1970. If a converted date looks absurd, check the unit first. This tool's Seconds and Milliseconds toggle exists precisely to resolve that confusion in one click.
UTC versus local time
A Unix timestamp itself carries no time zone. It marks the same instant everywhere on Earth; the number is identical whether you are in Tokyo or New York. Time zones enter the picture only when you convert that instant into a human-readable date, which is why the same timestamp displays as different wall-clock times in different places.
This converter shows both forms: your local time, formatted using your device's time zone, and UTC, the universal reference. Storing and transmitting timestamps in UTC, then converting to local time only for display, is the standard practice that avoids an entire class of off-by-hours bugs, especially around daylight saving time changes.
The Year 2038 problem
Many older systems store Unix time in a signed 32-bit integer, which can hold a maximum value of 2,147,483,647. That ceiling is reached at 03:14:07 UTC on January 19, 2038. One second later the counter overflows and wraps around to a large negative number, which those systems interpret as a date back in 1901.
This is the modern echo of the Year 2000 problem, and it threatens embedded devices, legacy databases, and any code still using 32-bit time. The fix is to store time in a wider 64-bit integer, which pushes the limit hundreds of billions of years out. This tool itself runs in your browser using JavaScript's built-in date handling rather than 32-bit time, so it converts dates far beyond 2038 without issue.
Converting in both directions
Going from a timestamp to a date means treating the number as seconds since the epoch and adding them on. The reverse, turning a date into a timestamp, computes how many seconds lie between the epoch and that moment. The converter does both: paste an epoch value to read its date, or pick a date in the picker to get its timestamp.
The relative-time readout, such as "3 hours ago," is derived by subtracting the timestamp from the current moment and describing the gap in plain language. It is handy for sanity-checking a value at a glance, since a log entry that claims to be from two years in the future is obviously suspect.
Where you will meet Unix time
Unix timestamps are everywhere in software. Server logs stamp each line with one so events can be ordered precisely. REST APIs return them in fields like created_at and expires_at because they are language-neutral and compact. Databases use them for sorting and for time-window queries, and JWTs encode expiry as a Unix timestamp.
For developers and analysts, reading these values quickly is a daily need. When you are debugging an API response, scanning a log file, or checking when a token expires, dropping the raw number into a converter turns an opaque integer into a date you can reason about, in both your local time and UTC, in seconds or milliseconds.
Frequently asked questions
What is a Unix timestamp?
Is my timestamp in seconds or milliseconds?
What time zone does the converter use?
What is the Year 2038 problem?
Is my data sent to a server?
Related tools
Keep going with these handy tools