Unix Timestamp Converter
Convert between Unix epoch time and a human-readable date, in either direction, in any timezone. Nothing you enter ever leaves your browser.
Two directions, one selected timezone
Unix seconds → date multiplies your input by
1000 and hands it to JavaScript's Date object,
which is always internally UTC-based; the timezone dropdown
only controls how that instant is displayed, via Intl.DateTimeFormat. Date → Unix
seconds works the other way: it treats what you typed
as a wall-clock reading inside the selected timezone, works out
that zone's real UTC offset at that moment (accounting for
Daylight Saving Time), and converts to the correct underlying
instant before dividing by 1000 and flooring.
Worked example
Unix timestamp 1755072000 converts to Wednesday, August 13, 2025, 8:00:00 AM UTC — in
milliseconds, that's 1755072000000. Switch the
timezone to Europe/Athens (UTC+3 in August) and the same
timestamp displays as 11:00:00 AM instead — the
underlying instant hasn't moved, only its local reading has.
Going the other way, entering 2026-08-13 10:00:00 with Europe/Athens selected
produces Unix timestamp 1786604400, which is 3
hours (10,800 seconds) earlier than the 1786615200
you'd get typing the identical wall-clock numbers with UTC
selected — because "10am in Athens" and "10am UTC" are two
different real moments.
Frequently asked questions
What exactly is a Unix timestamp?
The number of seconds elapsed since 00:00:00 UTC on January 1, 1970 (the "Unix epoch"), ignoring leap seconds. It's the standard way computers store a point in time as a single number instead of a calendar date — timezone-independent by construction, since it counts seconds from one fixed instant rather than from a local midnight that shifts by zone.
Why does this show both seconds and milliseconds?
Because the two units are both extremely common and easy to confuse. Most Unix/POSIX APIs, and the "unix timestamp" you'll see in most databases and server logs, use seconds. JavaScript's own Date.now() and new Date(...).getTime(), on the other hand, use milliseconds. Mixing the two up is a classic bug — feeding a seconds value where milliseconds are expected lands you in 1970, and the reverse overflows into a date thousands of years out — so this tool always shows both, side by side, for whichever direction you're converting.
Does converting a date use my browser's timezone, or the one I pick here?
The one you pick in the timezone dropdown, not necessarily your system's timezone. When you type a date and time and convert it to a Unix timestamp, this tool treats what you typed as a wall-clock reading IN THE SELECTED ZONE and works out the correct underlying instant — so you can convert "2026-08-13 09:00 in Madrid" to its Unix timestamp correctly even if your own computer is set to Tokyo time. The same selected zone controls how a Unix timestamp is displayed back as a human date.
Can I convert dates before 1970?
Yes — Unix timestamps go negative for any instant before the epoch, and this tool handles negative values the same as positive ones in both directions. There's no arbitrary lower bound built in, though extremely old or far-future dates are ultimately limited by what JavaScript's own Date object can represent (approximately ±273,790 years from 1970, far beyond any practical use here).
What about the exact moment of a leap second?
Unix time famously doesn't count leap seconds — every day is defined as exactly 86,400 seconds, and the rare leap second that UTC occasionally inserts gets absorbed rather than represented as its own distinct timestamp. This tool follows that same standard convention (same as your operating system's clock and virtually every other Unix-timestamp tool), so it isn't a source of error introduced here specifically.
Is my input sent anywhere?
No. Every conversion happens entirely in your browser using JavaScript's built-in Date object and the Intl API — nothing you type or paste is sent to a server, logged, or stored. That's true for every tool on this site.