Short answer: put a number in the timestamp box and choose seconds or milliseconds; or type an ISO date. Either way you get the ISO 8601 string, the UTC and local renderings, both Unix forms, the weekday, the offset and the UUIDv7 hex prefix.
Unix time in one paragraph
Unix time counts from 1970-01-01T00:00:00Z. It has no time zone: it is a count of elapsed seconds (or milliseconds), which is why two devices in different countries show different clock times for the same value. Every conversion here starts from that instant, then renders it in UTC, in your local zone and as the raw numbers.
Why the unit is a setting, not a guess
Many converters look at the digit count: 10 digits means seconds, 13 means milliseconds. That heuristic breaks for dates far from now — 1973 in milliseconds also has 10 digits, and a 12-digit value is ambiguous. Making you choose costs one click and removes an entire class of silently wrong results. The result always shows both Unix forms so you can confirm which reading you meant.
Reading the rows
- ISO 8601 — the canonical UTC string with milliseconds, safe to store.
- UTC and local — the same instant, spelled for humans.
- Offset — the numeric offset your zone had at that instant, daylight saving included.
- Unix seconds / milliseconds — what to send to an API or a JWT claim.
- Relative — how far that instant is from now, in both directions.
- UUIDv7 prefix — the 12 hex characters a time-ordered identifier starts with.
Decoding a token instead? The JWT decoder readsexp, iat and nbf with the same maths applied to the claims.