Epoch Converter

An epoch timestamp (Unix time) is the count of seconds – or in many systems, milliseconds – that have elapsed since 1970-01-01T00:00:00Z. It’s a single signed integer with no timezone of its own, so it’s the canonical way to store “an instant in time” in databases, APIs, and log files.

Both conventions exist. Unix kernels, C time_t, and most APIs use seconds. JavaScript’s Date.now() and many newer APIs use milliseconds. This tool auto-detects: any input with absolute value ≥ 10¹² (≈13 digits, covering any millisecond timestamp from year 2001 onward) is treated as milliseconds; smaller values as seconds. The dropdown lets you force one if the heuristic is wrong (e.g. a very old date in milliseconds).

For Epoch → Date: the “Local” row is your browser’s timezone, “UTC” and “ISO 8601” are always UTC. The stats line at the top shows your detected timezone name and UTC offset. For Date → Epoch: the value you pick in the datetime input is interpreted in your local timezone – that’s how <input type="datetime-local"> is defined and there’s no UI to override it. If you need to enter a UTC date, mentally shift it before entering, or use the Epoch → Date direction with a known epoch value.

Yes. Negative epoch values are accepted in both directions. For example, -1000000000 seconds is 1938-04-24 22:13:20 UTC. The seconds calculation uses Math.floor(ms / 1000), which floors toward negative infinity – so -1500 ms becomes -2 s, matching the canonical Math.floor(Date.now()/1000) idiom. If you’d rather truncate toward zero, divide manually.

It’s timezone-free (the same instant has the same integer everywhere), monotonic if you use ms with subsecond resolution, trivially comparable (just < / >), and trivially differenced (subtract for elapsed time). Storing local datetime strings is what causes timezone bugs; storing epoch ms eliminates the entire category.

ISO 8601 is the machine format: 2025-01-01T00:00:00.000Z. UTC is the same instant in human-readable form: Wed, 01 Jan 2025 00:00:00 GMT. Local is the same instant rendered in your browser’s timezone using whatever format your locale prefers (US: 1/1/2025, 12:00:00 AM; UK: 01/01/2025, 00:00:00). All three represent the same moment.

Yes – but only because JavaScript uses 64-bit floats, not 32-bit ints, for Date arithmetic. The Y2038 problem is specific to systems that store epoch seconds in a signed 32-bit integer (max 2,147,483,647 = 2038-01-19 03:14:07 UTC). This tool’s internal math handles values far beyond that, up to about ±8.64×1015 ms (year ±275760), where JavaScript’s Date itself starts returning NaN.

Yes. The page loads three static files (HTML, CSS, JS) and then runs entirely in your browser. Your timestamps never leave the device – no fetch, no XHR, no analytics, no cookies. You can disconnect from the internet after the page loads and the tool still works.

Yes – free, unlimited, no signup, no watermark. Use the conversions anywhere. Attribution to is appreciated but not required.