Unix Timestamp Converter — Free HTML CSS JS Snippet

A Unix timestamp counts seconds (or, in many JavaScript APIs, milliseconds) since 00:00:00 UTC on January 1, 1970 — the "epoch." It's the backbone of how most systems store and compare points in time internally, but it's meaningless to read at a glance, which is why converting a log line's or a JWT's exp claim's timestamp into an actual date is one of the most common small tasks a developer does in a day.

Seconds versus milliseconds — the single most common bug

JavaScript's own Date object and Date.now() work in milliseconds, but the Unix timestamp standard (and most backend languages' native epoch functions) work in seconds. Mixing the two up produces a date either 1970-ish (treating a seconds value as milliseconds gives a date near the epoch) or thousands of years in the future (treating a milliseconds value as seconds). This converter makes the unit an explicit, visible choice via the unit-select dropdown rather than guessing — fromTimestamp() multiplies by 1000 only when seconds is selected, so the ambiguity that causes this bug in real code is impossible to hide here.

Two-way binding without a feedback loop

The timestamp field and the browser-native datetime-local input both update the *other* field on input, which risks an infinite update loop if implemented naively (input A changes, updates B, which fires B's input handler, which updates A, forever). This snippet avoids that by keeping each direction as a fully separate function — fromTimestamp() parses the numeric field and writes into dateInput.value via imperative assignment (which does not fire a synthetic input event in real browsers), and fromDate() does the reverse. Each field's own listener only ever triggers a write to the *other* field, never back to itself, which is what keeps the pair in sync without recursion.

Relative time via the built-in Intl API

Rather than hand-writing "3 hours ago" / "in 2 days" string logic — which inevitably accumulates edge cases around pluralization and unit boundaries — relativeTime() uses Intl.RelativeTimeFormat, a standard built into every modern browser specifically for this. It walks a list of unit thresholds from year down to second, picks the largest unit where the elapsed time is at least one full unit, and hands the rounded value to rtf.format(value, unit), which handles the "ago" vs. "in" phrasing, pluralization, and locale formatting automatically based on the sign of value.

Six simultaneous output formats

Once a valid date is established from either input, renderResults() derives six representations from the same underlying Date object: raw seconds, raw milliseconds, toISOString() (always UTC, the format most APIs expect in request bodies), toUTCString() (the RFC 7231 format used in HTTP headers like Date and Expires), toString() (formatted in the browser's local timezone, useful for sanity-checking what a timestamp means to the person actually looking at the page), and the Intl.RelativeTimeFormat relative string. Seeing all six side by side from one input is deliberately the point — it eliminates having to convert a value five separate times to check it against five different systems' expected formats.