Epoch & Unix Timestamp Converter
Convert Unix epoch timestamps to human-readable dates and back, in any IANA timezone. Auto-detects seconds, milliseconds, microseconds and nanoseconds, handles negative (pre-1970) values, flags Year-2038 overflow, and converts whole lists in batch with CSV export.
Current Epoch Time
Conversion Settings
Detecting your timezone…
Detection is by magnitude, not digit count: seconds < 10¹¹ ≤ milliseconds < 10¹⁴ ≤ microseconds < 10¹⁷ ≤ nanoseconds. Negative and fractional values are supported.
Conversion Result
Conversion result will appear here
Enter a value to see the conversion update as you type
Current timestamp in your language
const seconds = Math.floor(Date.now() / 1000); const millis = Date.now(); const iso = new Date().toISOString();
Try these timestamps:
Things worth knowing:
- • Unix time is UTC-based; timezones only affect display.
- • JavaScript returns milliseconds; most other runtimes return seconds.
- • POSIX time ignores leap seconds — every day is exactly 86,400 s.
- • Values above 2,147,483,647 s break signed 32-bit time_t (2038).
- • Named IANA zones follow DST; fixed offsets like UTC−5 never do.
- • Everything runs in your browser — nothing is uploaded.
About Epoch & Unix Timestamp Converter
An epoch converter turns Unix time — the count of seconds since 1970-01-01 00:00:00 UTC — into a date a human can read, and turns dates back into timestamps. This one detects the unit by magnitude rather than digit count, so seconds, milliseconds, microseconds and nanoseconds all resolve to the same instant, and it renders that instant in UTC, in your browser's timezone and in any IANA zone you pick, with DST applied from the zone's own rules.
Why use a Epoch & Unix Timestamp Converter?
Timestamps show up everywhere — log lines, JWT `exp` claims, database columns, API payloads — as bare integers that nobody can read at a glance, and the two classic failure modes (milliseconds parsed as seconds, or a wall-clock time interpreted in the wrong zone) produce dates that are wrong by decades or by hours. This converter removes the guesswork: it names the unit it detected, lets you override it, shows the same instant in every format you might need, and warns when a value would overflow a signed 32-bit time_t.
Who is it for?
Backend and frontend developers debugging time-stamped data, SREs reading logs during an incident, database administrators migrating timestamp columns, API integrators reconciling `iat`/`exp`/`nbf` claims, and anyone who has to explain why an event appears to have happened in 1970 or in the year 56,000.
How to use the tool
Pick a conversion mode: Epoch → Human, Human → Epoch, or Batch for a whole list of timestamps.
Choose a display timezone from the IANA selector — it defaults to your browser's zone, and the tool shows that zone's current UTC offset and abbreviation.
In Epoch → Human, paste the timestamp; the badge reports the unit detected by magnitude (seconds, milliseconds, microseconds or nanoseconds) and the Unit dropdown lets you override it.
In Human → Epoch, type a date as free text — ISO 8601 with or without an offset, YYYY-MM-DD HH:mm:ss, RFC 2822, JavaScript Date#toString(), Unix date or git log output, month names (Nov 14, 2023 10:00 PM or 14-Nov-2023), US M/D/YYYY (always read month first; 14/11/2023 is rejected rather than guessed), or now / today / tomorrow — or use the date picker, whose value is read as wall-clock time in the selected zone.
Read the result block: epoch seconds, milliseconds and microseconds, ISO 8601 in UTC and in the selected zone, human strings for both, RFC 2822, relative time, day of week, day of year and ISO week number.
Watch for the badges — an amber Year-2038 badge above 2,147,483,647 seconds and a blue notice for negative timestamps that fall before 1970.
Copy any single row with its copy button, copy the whole block, or download it as a text file; in Batch mode export every row as CSV.
Use “Copy shareable link” to share the exact timestamp and timezone, or grab a ready-made “current timestamp” snippet for JavaScript, Python, Go, Java, PHP, Ruby, C#, SQL or Bash.
Frequently Asked Questions
How do I convert a Unix timestamp to a human-readable date?
Paste the timestamp into the Epoch → Human field. The tool detects the unit, converts the value to an instant, and renders it in UTC, in the IANA timezone you selected, as ISO 8601 (both UTC and with the zone's offset), as an RFC 2822 date and as relative time such as “3 days ago”. Each row has its own copy button. For the reverse direction, switch to Human → Epoch and type a date as ISO 8601, RFC 2822, Date#toString() output, a month-name date such as “Nov 14, 2023 10:00 PM”, or a month-first M/D/YYYY date, or use the picker. Everything is computed in your browser with the JavaScript Intl API — no request is made.
What is the difference between a 10-digit and a 13-digit timestamp?
Ten digits is normally seconds since the epoch, thirteen is milliseconds — JavaScript's Date.now() and most JVM APIs return milliseconds, while time() in PHP, time.time() in Python and time.Now().Unix() in Go return seconds. Sixteen digits is microseconds (Postgres, some tracing systems) and nineteen is nanoseconds (Go's UnixNano, Prometheus). This tool detects by magnitude, not by digit count: values under 10¹¹ are seconds, under 10¹⁴ milliseconds, under 10¹⁷ microseconds, and anything larger is nanoseconds. That is why a leading space, a 12-digit millisecond value or a negative number still resolves correctly.
Is this converter private, and how accurate is the timezone handling?
It runs entirely in your browser via JavaScript — your timestamps never reach a server and are never logged. Verify in DevTools' Network tab: zero HTTP requests while converting. Timezone conversion uses the Intl.DateTimeFormat API, which reads your browser's bundled IANA tz database, so daylight-saving transitions, historical offset changes and half-hour or 45-minute offsets such as Asia/Kolkata and Pacific/Chatham are applied from the same rules your operating system uses. Zones are listed with Intl.supportedValuesOf('timeZone') when the browser supports it, with a curated fallback list otherwise.
Should I store Unix timestamps or ISO 8601 strings in a database?
Store an instant, not a wall-clock reading. A Unix integer is compact, sorts and compares numerically, and is unambiguous; ISO 8601 with an explicit offset (2023-11-14T22:13:20Z) is self-describing and readable in a log dump. Both are fine — a native timestamptz column in PostgreSQL is better than either because it round-trips through the server's tz database. What is never fine is storing a local time without its zone: the value becomes unrecoverable across DST transitions and server migrations. For future appointments, store the wall-clock time plus the IANA zone name, because governments change offsets.
What is the Year 2038 problem?
At 03:14:07 UTC on 19 January 2038, Unix time reaches 2,147,483,647 — 2³¹−1, the largest value a signed 32-bit time_t can hold. One second later it wraps to a negative number and dates read as December 1901. This tool shows an amber badge for any value above that ceiling so you can spot 32-bit exposure while testing. Modern 64-bit systems are unaffected, but embedded firmware, 32-bit ABIs, MySQL's TIMESTAMP column (which tops out in 2038, unlike DATETIME), legacy file formats and serialization schemas with 32-bit time fields all still need auditing.
How do I convert a whole column of log timestamps at once?
Switch to Batch mode and paste one timestamp per line; each line is detected and converted independently, and the table shows the unit, epoch seconds, ISO 8601 UTC, the selected zone's local time and relative time, with invalid lines flagged in place instead of silently dropped. Export the whole table as CSV to join it back onto your data. You can also force one unit for every row when you know the source format. For conversion inside a pipeline, the code-snippets panel gives the equivalent one-liners for Bash, Python, Go, SQL and six other languages.
Why does the same timestamp show a different time for me than for a colleague?
Because the timestamp is a UTC instant and only its presentation is local. Timestamp 1700000000 is 22:13:20 UTC, 23:13:20 in Europe/Budapest and 17:13:20 in America/New_York — the same moment, three readings. Daylight saving makes it worse: a named IANA zone such as America/New_York switches between EST (−05:00) and EDT (−04:00) at the dates in the tz database, so the offset depends on the instant, not on the zone alone. A fixed offset like UTC−05:00 never shifts. Always pin a zone by IANA name; abbreviations such as CST are ambiguous across several zones.
What are the limits — negative timestamps, leap seconds, sub-second precision?
Negative values are fully supported: −86400 is 1969-12-31 UTC and −2208988800 is 1900-01-01, rendered on the proleptic Gregorian calendar with a notice that the instant precedes the epoch. POSIX Unix time does not represent leap seconds — every day is exactly 86,400 seconds, so the 27 leap seconds inserted since 1972 are simply absent; use TAI or UT1 if you need them. Fractional seconds are accepted and sub-millisecond digits are preserved exactly in the microsecond and nanosecond rows. The outer bound is ±8.64×10¹⁵ ms, roughly ±273,790 years. For calendar arithmetic on the result, see the date calculator and week number calculator.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.