Timestamp Converter

What it does

Paste a Unix timestamp or a date string and get every representation you are likely to need at once: seconds, milliseconds, ISO 8601 in UTC, ISO 8601 with the offset of a timezone you pick, a full human-readable rendering, the HTTP date format, and how long ago it was. A live clock at the bottom shows the current time in the same zone so you always have a reference point, and the “Use now” button drops the current second into the input.

Unit detection is automatic and based on digit count, so 10-digit seconds, 13-digit milliseconds, and 19-digit nanoseconds all just work. When the guess is wrong, and it will be for dates far from the present, the unit selector overrides it.

How it works

Parsing and arithmetic use the JavaScript Date object, which counts milliseconds from 1970-01-01T00:00:00Z. Everything timezone-aware is delegated to Intl.DateTimeFormat, and the zone list comes from Intl.supportedValuesOf, which on a current browser returns just over 400 IANA zone names. Those rules come from the IANA Time Zone Database shipped with your browser, so offsets are historically correct rather than a flat guess of the zone’s current offset. Nothing is sent to a server.

ISO 8601, RFC 3339, and the formats that bite

A Unix timestamp is an absolute instant with no timezone attached. The moment you render it as a date you have made a timezone choice, whether deliberately or by accident, and that is where most timestamp bugs come from. A log line that says the incident started on the 27th and a dashboard that says the 28th are usually the same instant seen from two zones.

For text formats, prefer RFC 3339. It is a strict profile of ISO 8601 built for internet protocols: full date, full time, and a mandatory offset, either Z or ±hh:mm. ISO 8601 itself also permits ordinal dates, week dates, durations, intervals, and omitted offsets, none of which a typical parser handles, so “ISO 8601” in an API contract is much weaker than it sounds. If you need to carry a timezone identifier rather than just an offset, RFC 9557 extends RFC 3339 with a bracketed suffix such as 2026-07-27T14:30:00+01:00[Europe/London], which is the format the Temporal API uses.

Offset and timezone are not the same thing, and the difference matters for anything scheduled in the future. +01:00 tells you what the clock read; it does not tell you what it will read in November. Store a zone name for future events and an absolute instant for past ones.

Two smaller traps. Unix time is not real UTC: POSIX defines every day as exactly 86,400 seconds, so leap seconds are unrepresentable and are smeared or repeated by the platform. And the 32-bit signed second counter overflows on 2038-01-19T03:14:07Z, which is close enough now that embedded and legacy systems are worth auditing rather than joking about.

When to reach for it

• Correlating a log line, a trace span, and a database row that were written in three different formats.
• Checking what a JWT exp or iat claim actually means before deciding a token is broken.
• Working out when a certificate, cache entry, or scheduled job fires in the timezone of the people it affects.
• Confirming that a timestamp from another system is seconds and not milliseconds, before you divide by a thousand in the wrong place.

Related tools

• Cron expression parser for the schedule that produced or will produce the instant.
• UUID generator and inspector to pull the embedded timestamp out of a v1, v6, or v7 identifier.
• HTTP status reference for the response whose Date and Expires headers you are reading.

Also nearby: the JWT decoder turns exp and nbf claims into instants you can paste straight in here, and the TLS certificate inspector does the same for notBefore and notAfter.