Unix Timestamp Converter
Convert epoch time to a human date and back — live current Unix time, automatic seconds/milliseconds detection, plus UTC, ISO-8601, RFC-2822 and relative time. All in your browser.
Runs entirely in your browser — nothing is sent to a server. The clock and every conversion use your device's own time and the built-in Date engine. No network requests, no logging, no analytics — disconnect from the internet and it still works.
Auto-detect treats a value of 12 or more digits as milliseconds. Human dates like 2026-07-08, 2026-07-08 14:30:00 or an ISO string are parsed with your browser's Date engine.
Batch convert (many at once)
Paste a whole list — one timestamp per line, freely mixing Unix seconds, milliseconds and ISO-8601 dates. Each line is auto-detected on its own and converted in place; the output stays line-for-line with your input, so blank or unrecognised lines are marked, never dropped or reordered.
Per line the same auto-detect runs: a numeric value with 12 or more integer digits is read as milliseconds, fewer as seconds; anything non-numeric is parsed as an ISO-8601 / date string by your browser. The [s] / [ms] / [iso] tag shows how each line was read. Blank lines show (blank line) and garbage shows (invalid) — output order matches input order exactly.
Converted lines appear here — one output line per input line.
What a Unix timestamp is
A Unix timestamp — also called epoch time or POSIX time — is the number of seconds that have passed since the Unix epoch: midnight UTC on 1 January 1970. Leap seconds are not counted, so it is a plain, monotonic integer that only ever grows. Because the count is anchored to UTC, one timestamp names the same instant everywhere on Earth, which is why databases, log files, JWT exp/iat claims and most APIs store it instead of a written-out date that would drag a timezone along. A present-day value is around 1.75 billion — ten digits. You can sanity-check any epoch in your head: divide by 31,557,600 (seconds in an average year) and add 1970 to get the approximate year.
Worked example: reading 1700000000
Paste 1700000000 into the box with the reading set to Seconds. Because 1,700,000,000 seconds is roughly 53.87 years, the result lands in late 2023 — precisely:
- UTC: 2023-11-14 22:13:20 (ISO-8601
2023-11-14T22:13:20Z, the trailingZmeaning Zulu/UTC) - New York (UTC−5 in November): 2023-11-14 17:13:20 — same calendar day, five hours earlier
- Tokyo (UTC+9): 2023-11-15 07:13:20 — already the next day
All three rows describe one identical instant; only the wall clock differs. Now paste the milliseconds form of the same moment, 1700000000000 (13 digits): auto-detect flips to milliseconds and you get the same November 2023 date. Drop three zeros and force Seconds, and 1700000000 is that date; force Milliseconds on the 10-digit value instead and it collapses to 1970-01-20, because 1.7 billion milliseconds is only about 19.7 days after the epoch.
Seconds vs milliseconds — the most common gotcha
Two resolutions are easy to mix up. Traditional Unix time counts whole seconds (10 digits today). JavaScript's Date.now(), Java's System.currentTimeMillis() and many web APIs count milliseconds — 1000× larger, 13 digits today. Get it wrong and the error is spectacular, not subtle: read a seconds value as milliseconds and you land 19 days after 1970; read a milliseconds value as seconds and you shoot to roughly the year 55,000. This tool auto-detects by length — 12 or more digits is treated as milliseconds — and the Read number as buttons force either interpretation when the guess is wrong.
Timezones and daylight saving
The timestamp itself has no timezone; it is a UTC second-count. A timezone only enters when you render the instant as a wall clock, and the result panel shows the UTC date and your device's local date side by side with its offset. The subtle trap is daylight saving: a single zone's offset changes across the year. New York is UTC−5 in winter but UTC−4 from spring to autumn, so the same city-name plus wall-clock time can point at two different instants an hour apart. Storing the epoch integer sidesteps all of this — convert to local only at the moment you display it.
Common epoch landmarks
Handy reference points for spotting roughly when a raw value falls (all seconds, UTC):
| Epoch (seconds) | UTC date/time | What it is |
|---|---|---|
-2208988800 | 1900-01-01 00:00:00 | Pre-epoch; the NTP/1900 base era |
-1 | 1969-12-31 23:59:59 | One second before the epoch |
0 | 1970-01-01 00:00:00 | The Unix epoch itself |
86400 | 1970-01-02 00:00:00 | Exactly one day (86,400 s) later |
1000000000 | 2001-09-09 01:46:40 | The "one billion seconds" party |
1234567890 | 2009-02-13 23:31:30 | The famous 1234567890 moment |
1700000000 | 2023-11-14 22:13:20 | The worked example above |
2147483647 | 2038-01-19 03:14:07 | Signed 32-bit ceiling (Y2038) |
The year 2038 problem
Software that stores Unix time in a signed 32-bit integer tops out at 2,147,483,647 seconds — 03:14:07 UTC on 19 January 2038. The next second overflows to a negative number and the date wraps back to December 1901. Anything modern uses 64-bit integers and is safe for about 292 billion years, but old embedded firmware, some binary file formats and legacy database columns still carry the ceiling, so it is worth knowing which your data uses before scheduling a far-future timestamp.
Want the full first-principles story — the epoch, timezone-agnostic UTC, the seconds/milliseconds test and Year 2038 in one place? Learn more in our Unix timestamp guide →
Negative and pre-1970 timestamps
Epoch time runs both directions: dates before 1970 are simply negative. -1 is one second before the epoch, and -2208988800 is 1 January 1900. They are well defined, but portability is uneven — some databases and language runtimes reject or mishandle negative epoch values, so treat pre-1970 timestamps as a mild risk when data crosses systems. If you paste a large negative number and auto-detect calls it milliseconds, force the Seconds reading.
Common mistakes
- Seconds/milliseconds mix-up. The single biggest source of "my date is in 1970" (or "in the year 55,000") bugs. Check the digit count: 10 today means seconds, 13 means milliseconds.
- Assuming a timestamp has a timezone. It does not — it is UTC. Apply the zone only when formatting for a human, and remember DST shifts the offset.
- Loose date strings.
07/08/2026is 7 August or 8 July depending on locale. Feed the parser an unambiguous ISO string (2026-07-08) to avoid a silent month/day swap. - Ignoring 32-bit limits. Scheduling anything past January 2038 through legacy 32-bit code will overflow into 1901.
Honest limits
Human-date parsing here uses your browser's built-in Date engine. Unambiguous ISO-8601 strings parse identically everywhere, but loose formats like 07/08/2026 differ across browsers and locales — prefer ISO for anything ambiguous. Local dates are rendered in your device's current timezone and daylight-saving rules as your system knows them, so a machine with the wrong clock or an out-of-date time-zone database will show the wrong local time even though the epoch value is correct.