Unix Timestamp Converter
Convert Unix timestamps to human-readable dates and back, with timezone support and a live current timestamp.
How to use
- Choose your time zone at the top (defaults to your local zone).
- Paste a Unix timestamp to convert it to a human date, or pick a date and time to get the timestamp.
- See the result in your zone and in UTC, plus the live current timestamp.
- Copy any value with one click.
What is a Unix timestamp?
A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 — a moment known as the Unix epoch. Instead of storing a date as a string like "10 June 2026, 3:45 PM", systems store it as a single integer, such as 1781106300. This makes time easy to store, compare and do arithmetic on: working out the gap between two moments is just a subtraction. Because the count is always measured in UTC, a timestamp represents the same instant everywhere in the world, regardless of local time zones.
This converter turns Unix timestamps into readable dates and readable dates back into timestamps, in any time zone, and shows you the current Unix time updating live. Everything runs in your browser, so it is instant and private.
Converting Unix time to a human date
To make a timestamp meaningful to people, it has to be converted into a calendar date and time. Enter a Unix timestamp and this tool shows the corresponding date in your chosen time zone, in UTC, and as a friendly relative time such as "3 hours ago" or "in 2 days". It automatically detects whether your number is in seconds (the standard, around 10 digits today) or milliseconds (13 digits, used by JavaScript and many APIs), so you can paste either and get the right result. This is exactly what you need when reading a log file, a database record or an API response that stores time as an integer.
Converting a human date to Unix time
The reverse is just as common: you have a specific calendar date and time and need its Unix timestamp — for scheduling, filtering records, or setting an expiry. Pick a date and time, choose the time zone it should be interpreted in, and the converter gives you the exact epoch value in both seconds and milliseconds. Time-zone handling is the subtle part here: the same wall-clock time corresponds to different instants in different zones, so the tool computes the correct offset (including daylight saving time) for the zone and date you choose, rather than assuming UTC or your local zone.
Time zones and UTC
A Unix timestamp itself has no time zone — it is always counted from the UTC epoch. Time zones only matter when you display a timestamp as a date or when you interpret a human date you are converting to a timestamp. That is why this tool offers full time-zone support: you can see what a timestamp looks like in New York, London, Tokyo or any other zone, and you can enter a local time in a specific zone and get the correct epoch value. Daylight saving time is handled automatically, because the converter calculates the actual offset that applied in that zone on that particular date. When in doubt, UTC is the safe, unambiguous reference, and it is always shown alongside your selected zone.
Seconds vs milliseconds
One frequent source of bugs is the difference between seconds and milliseconds. Classic Unix time and most back-end languages count in seconds, while JavaScript's Date.now() and many web APIs count in milliseconds — a factor of 1,000 apart. Mixing them up produces dates that are wildly wrong (off by decades). This converter detects the likely unit from the size of the number and shows both, so you can always confirm you are using the right one. As a rule of thumb, a present-day timestamp is about ten digits in seconds and thirteen digits in milliseconds.
The year 2038 problem
Many older systems store Unix time in a signed 32-bit integer, which can only count up to 2,147,483,647 seconds — a value reached at 03:14:07 UTC on 19 January 2038. After that instant, a 32-bit counter overflows and wraps around to a negative number, misinterpreting the date as December 1901. This is the famous "Year 2038 problem", a distant cousin of the Year 2000 bug. Modern systems avoid it by storing time in 64-bit integers, which push the limit billions of years into the future. It is a useful reminder that timestamps, for all their simplicity, depend on how many bits you use to store them.
Common use cases
- Reading logs. Convert the epoch times in server and application logs into readable dates.
- APIs and webhooks. Decode timestamps in API responses, or generate one to send in a request.
- Databases. Translate stored epoch columns into dates, or work out the timestamp for a query filter.
- Tokens and expiry. Check the
iatandexpvalues inside a JWT, which are Unix timestamps. - Scheduling. Compute the exact timestamp for a future event in a specific time zone.
How to use this tool
Pick your time zone at the top, then use either converter: paste a Unix timestamp to see the human date, or choose a date and time to get the timestamp. The current Unix time is displayed live so you always have "now" to hand, and every result can be copied with one click. There is nothing to install and no sign-up, and because all the conversion happens in your browser, it is fast, works on any device, and keeps your data private.