Epoch & Unix Timestamp Converter

A Unix timestamp is the number of seconds since the Unix epoch, 1970-01-01 00:00:00 UTC. It is how computers store and exchange time internally — in logs, JWT exp/iat claims, cookies, databases, and APIs — because it is timezone-free and trivial to compare. This converter runs both directions: paste an epoch to expand it into ISO 8601, a human-readable UTC string, and a relative "time ago / from now" description, and enter a date to get its epoch in both seconds and milliseconds.

Seconds or milliseconds. Unix time appears in two common resolutions: seconds (10 digits for current dates) and milliseconds (13 digits), the latter being JavaScript's Date.now() default. Mixing them up is the number-one timestamp bug — a millisecond value read as seconds lands 50,000× too far in the future. This tool auto-detects the unit by magnitude and tells you which it assumed.

How you'll use it. Paste an epoch from a log line or token to see the real moment it refers to; when auditing a JWT, converting the exp claim tells you at a glance whether a token is long-lived or already expired, and iat shows when it was issued — decode the token's payload segment with the Base64 tool first to read those claims. Going the other way, enter a human date to produce the integer a query filter (created_after), a token exp, or a cron schedule expects. In incident timelines, normalizing every source's epoch to UTC ISO 8601 removes the ambiguity that wrecks correlation.

Parsing rules and pitfalls. For the date→epoch direction, ISO 8601 with an explicit zone (Z for UTC, or an offset like +05:30) is unambiguous — always prefer it. A date-only string like 2024-01-31 is interpreted as UTC midnight, but a date-time without a zone is read in the browser's local timezone, so two people can get different epochs from the same string. Non-standard formats (31/01/2024 vs 01/31/2024) parse inconsistently across engines. Also remember the "Year 2038 problem": a signed 32-bit seconds counter overflows on 2038-01-19, so long-lived systems must use 64-bit time.

Defensive angle. Security tokens live and die by timestamps. Set short, explicit expiries (exp) and validate them on every request; a token with no expiry is valid forever if leaked. Log in UTC to make cross-system correlation reliable, require an explicit timezone on dates you accept, range-check them, and be suspicious of records whose timestamps are impossibly future-dated or clustered — a sign of clock tampering or forged evidence.