Unix Timestamp Converter

Timestamp to date

Max 64 bytes · Seconds or milliseconds, auto-detected · Converts automatically as you type

Unit

Date to timestamp

Interpreted in your browser's local timezone

A Unix timestamp (also called epoch time or POSIX time) is a single number representing a point in time: the number of seconds — or, in many programming environments, milliseconds — that have elapsed since 1970-01-01T00:00:00 UTC, the “Unix epoch.” Because it’s just one number with no embedded timezone or calendar formatting, it’s the most common way computers store and exchange points in time internally — in databases, log files, API responses, JSON Web Tokens, and file metadata.

That same simplicity is what makes timestamps hard to read at a glance. 1753452730 is unambiguous to a computer but tells a person nothing without a conversion step — and that step has a common trap: whether the number is in seconds or milliseconds. A timestamp in milliseconds is exactly 1,000 times larger than the same instant in seconds, so treating one as the other doesn’t produce an error, it silently produces a wildly wrong date (usually decades off). This tool auto-detects the unit by digit count — 10 digits reads as seconds, 13 as milliseconds, matching the ranges in common use today — but never guesses silently past your intent: the unit toggle always overrides auto-detection when set explicitly.

Converting a timestamp to a date only gets you halfway to being useful, though, because “a date” isn’t one fixed thing — it depends on which timezone you’re reading it in. This tool shows a timestamp’s UTC representation, your browser’s resolved local timezone (named explicitly, not just as an offset), and the ISO 8601 form all at once, specifically so they can be compared side by side rather than looked up one at a time. The reverse direction works the same way in reverse: enter a date and time in your local timezone, and get back both the seconds and milliseconds forms of its Unix timestamp, ready to paste into whichever system expects which unit.

All conversion happens locally using the browser’s built-in Date and Intl.DateTimeFormat APIs — including timezone and daylight-saving-time resolution, which those APIs handle correctly without needing an external timezone database. Nothing you enter is sent anywhere.

Examples

Frequently asked questions

Should I use seconds or milliseconds?
It depends on the system that produced the timestamp. Unix/POSIX time and most server-side APIs (databases, cron, date +%s) use whole seconds since the epoch. JavaScript's Date.now() and most browser and Node.js APIs use milliseconds. This tool auto-detects which one you've pasted by digit count — a 10-digit number is read as seconds, a 13-digit number as milliseconds — but you can force either interpretation with the unit toggle if a value is ambiguous.
What is "the epoch"?
The Unix epoch is 1970-01-01T00:00:00 UTC — the reference point every Unix timestamp counts from. A timestamp of 0 is exactly the epoch; positive values are seconds (or milliseconds) after it, negative values are before it.
How does this tool handle timezones and daylight saving time?
A Unix timestamp itself has no timezone — it's a count of seconds since a single fixed instant. This tool converts that instant into your browser's local timezone using the Intl.DateTimeFormat API, which applies whatever daylight saving rules were in effect for that zone on that specific date. That's why the UTC offset shown can differ for two dates in the same zone a few months apart.
What is the Year 2038 problem, and does it affect this tool?
Many older systems store Unix time as a signed 32-bit integer, which overflows on 2038-01-19T03:14:08 UTC and wraps to a negative number, corrupting the date. This tool doesn't have that problem: JavaScript stores timestamps as 64-bit floating-point numbers, safely representing dates roughly 273,790 years in either direction from the epoch. The 2038 problem is still very real for the embedded systems, older databases, and 32-bit software that produced the timestamp you're inspecting, though.
Why do the UTC and local results show different times?
They describe the exact same instant, just expressed in two different reference frames. UTC is a fixed, zone-independent baseline; local time applies your browser's timezone offset (and daylight saving, if applicable) on top of it. Converting a server log timestamp (usually recorded in UTC) into your own local time is one of the most common reasons to use this tool.