About Timestamp Converter
Timestamp Converter turns Unix epoch numbers into human dates and back again — and shows the same instant in every major timezone simultaneously. Paste a 10-digit (seconds) or 13-digit (milliseconds) timestamp and it auto-detects the precision. Pick any ISO 8601 string, RFC 2822 date, or human-typed datetime and get the matching epoch values. It's the daily-use utility for backend engineers staring at log lines, anyone debugging a JWT exp claim, or PMs scheduling a release across continents.
- No uploads
- Browser-only
- Works offline
- 100% free
How it works
- 1
Paste a timestamp or date
Enter a Unix epoch (seconds or milliseconds — both are detected) or an ISO 8601 / human datetime string. The other format fills in instantly.
- 2
Inspect every timezone
A side panel shows the same instant rendered in UTC, your local zone, and major cities — useful for coordinating standups or release windows.
- 3
Copy the format you need
One-click copy for Unix seconds, Unix milliseconds, ISO 8601, RFC 2822, and a human-readable rendering.
Epoch time, and why computers count from 1970
A Unix timestamp is a single integer: the number of seconds since the Unix epoch, 00:00:00 UTC on 1 January 1970. That's it — no timezone, no formatting, just a count. Storing time as one number is enormously convenient: comparisons, sorting and arithmetic become plain integer maths, and there's no ambiguity about format or locale. It's why the value sits underneath databases, logs, APIs and file systems everywhere.
The flip side is that the raw number is meaningless to humans and silently assumes UTC. A timestamp like 1700000000 doesn't say what date it is or which timezone you're in — it's seconds from the epoch, and turning it into a readable date requires a conversion that you (or your code) must apply consistently.
Seconds vs milliseconds — the off-by-1000 bug
The most common timestamp bug is a units mismatch. Classic Unix time counts seconds, but JavaScript's Date.now() and many modern APIs return milliseconds since the same epoch. The two look similar but differ by a factor of 1000, and mixing them throws dates wildly off — a milliseconds value read as seconds lands tens of thousands of years in the future; a seconds value read as milliseconds lands in January 1970.
A quick sanity check: a seconds timestamp for "now" in the 2020s is about 10 digits (1.7 billion); a milliseconds timestamp is about 13 digits (1.7 trillion). If your date is absurdly far off, you almost certainly multiplied or divided by 1000 in the wrong direction. Always confirm which unit your source emits before converting.
UTC vs local time, and ISO 8601
A timestamp is an absolute instant, but the date and time you display depend on a timezone. The same integer is "22:13 in London" and "17:13 in New York" on the same day — same instant, different wall-clock. Treat the stored timestamp as UTC and only apply a timezone offset for display; storing local times invites confusion the moment a server, a user, or daylight-saving boundaries move.
For a human-readable yet unambiguous format, use ISO 8601 — e.g. 2023-11-14T22:13:20Z, where the trailing Z means UTC ("Zulu"). It sorts correctly as plain text, has no day/month ordering ambiguity, and is the format to prefer whenever you write a timestamp down for another system to read.
The Year 2038 problem
Systems that store Unix time in a signed 32-bit integer can only count up to 2,147,483,647 seconds — which is reached at 03:14:07 UTC on 19 January 2038. One second later the counter overflows and wraps to a large negative number, throwing affected software back to December 1901. This is the Year 2038 problem, the spiritual successor to Y2K, and it's a real concern for embedded devices, legacy databases and old file formats that still use 32-bit time fields.
The fix is to store time in a 64-bit integer, which pushes the overflow billions of years out — comfortably past any practical horizon. Most modern platforms have already moved to 64-bit time, but anything long-lived or low-level is worth checking. If you work with epoch values in code, the neighbouring formats are covered in the developer Learning Center hub.
Frequently asked questions about Timestamp Converter
How does it tell Unix seconds from milliseconds?
By digit count and magnitude. A 10-digit number near 1.7×10^9 is treated as seconds (sometime in the 2020s–2030s); a 13-digit number is treated as milliseconds. You can override the detection with a toggle if you're working with very old or far-future timestamps that fall outside the heuristic.
Does it handle Daylight Saving Time correctly?
Yes. Conversion uses the browser's built-in Intl API, which carries IANA tzdata. So a US/Eastern timestamp in March picks up EDT vs EST automatically — no manual offset arithmetic needed. If your tzdata is out of date (very old browsers), updating your OS or browser refreshes the rules.
Can I convert nanosecond or microsecond timestamps?
Yes — toggle precision to microseconds (16 digits) or nanoseconds (19 digits). Conversion truncates to the nearest millisecond for the human rendering because JavaScript's Date object doesn't support sub-millisecond resolution, but the original precision is preserved on copy-out.
Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.