Unix Timestamp Converter

A Unix timestamp (also called Epoch time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. It is the standard way computers store and exchange points in time internally, because a single integer is unambiguous, timezone-independent, and trivial to compare or sort — unlike a formatted date string, which depends on locale, format, and timezone assumptions that vary between systems. You will see Unix timestamps everywhere in software: API responses, server logs, database `created_at` columns, JWT expiry claims, cache expiry headers, and cookie `expires` values all commonly use them. There are two flavours in common use: seconds and milliseconds. Unix systems, cron, and most server-side languages (PHP's `time()`, Python's `time.time()` truncated) traditionally use seconds, giving a 10-digit number for dates in the current era (roughly 2001–2286). JavaScript's `Date.now()` and most browser and Node.js APIs use milliseconds, giving a 13-digit number for the same range. Pasting a 10-digit number into a tool expecting milliseconds — or vice versa — produces a wildly wrong date (either 1970 or a date thousands of years away), which is one of the most common timestamp bugs in web development. This tool sidesteps that by counting the digits of whatever you paste: 1–10 digits is treated as seconds, 11 or more digits as milliseconds, before running it through JavaScript's native `Date` object. The UTC/local split matters because a raw timestamp has no timezone of its own — it is an absolute instant, and "what time was it" only becomes meaningful once you pick a reference frame. Showing both columns side by side is deliberate: UTC is what you want when comparing logs across servers in different regions or writing timezone-agnostic documentation, while local time is what you want when explaining to a colleague or end user what a value means for them. `Intl.DateTimeFormat` with an explicit `timeZone: 'UTC'` option produces the first column; the same formatter with no `timeZone` override falls back to whatever timezone your browser (and therefore your operating system) is currently configured with for the second. Everything here is plain `Date` arithmetic — no date library, no server round-trip. `new Date(timestamp)` (after normalising to milliseconds) does the heavy lifting for the timestamp-to-date direction, and `Date.getTime()` divided by 1000 does the reverse for the date-to-timestamp direction, rounded down to the nearest whole second since Unix time is conventionally expressed in whole seconds.