Epoch time in one paragraph
A Unix timestamp counts seconds since 1970-01-01 00:00:00 UTC, no timezone, no daylight saving, just an integer that means the same instant everywhere. That's why it dominates logs, databases, JWTs, TLS certificates and APIs: comparing two moments becomes integer subtraction. The awkwardness begins only when a human has to read one, which is what this converter is for.
Seconds or milliseconds?
The most common conversion error is a factor of a thousand. Unix convention and most system logs use seconds (10 digits for current dates); JavaScript's Date.now(), Java, and many APIs use milliseconds (13 digits). Paste a millisecond value into a seconds-based tool and you get a date fifty thousand years away. This converter detects the magnitude automatically and tells you which interpretation it chose, so a mixed-up value is caught immediately.
Debugging with timestamps
Typical uses: turning the exp claim of a JWT into "expired 12 minutes ago", correlating an incident report ("around 2:30pm") with epoch-stamped logs, checking whether a certificate's notAfter has passed, and computing exact intervals between two events. On a shell you can go the other way with date -d @1767225600 (GNU) or date -r 1767225600 (BSD/macOS), but a browser tab is quicker when you're already staring at a log viewer.
The year 2038, briefly
Signed 32-bit timestamps overflow on 19 January 2038 at 03:14:07 UTC. Modern 64-bit systems store time_t as 64 bits and are fine for the next few hundred billion years, but embedded devices, old filesystems and legacy database schemas using INT columns for epoch values are not. If you administer anything with a projected lifetime past 2038 (industrial controllers, long-lived appliances) it's worth an audit now rather than a pager alert then.