Unix Timestamp Converter

Convert Unix seconds or milliseconds to ISO time and readable UTC dates.

Current Unix time

Loading

Seconds since 1970-01-01 00:00:00 UTC

Auto-detected unit: seconds

Selected unitseconds
ISO UTC2024-01-01T00:00:00.000Z
UTC stringMon, 01 Jan 2024 00:00:00 GMT
Browser local timeAvailable after load

A Unix timestamp counts the seconds elapsed since 1970-01-01T00:00:00Z, the POSIX epoch defined in IEEE Std 1003.1. Paste a value in seconds or milliseconds, and the converter returns the matching ISO 8601 / RFC 3339 string in UTC. Unit detection is length-based: thirteen or more digits parses as milliseconds, anything shorter parses as seconds. Negative values resolve to dates before 1970, which is useful for archival data and historic logs. Use this when you need to compare a database column, an HTTP header, or a JWT "iat" claim against a human-readable instant.

Common use cases

  • Reading database timestamps. Postgres, MySQL, and SQLite often store epoch seconds or milliseconds in integer columns. Drop the value here to see the wall-clock UTC instant before writing a migration or a backfill query that depends on the boundary.
  • Decoding JWT and OAuth claims. JWT "iat", "nbf", and "exp" claims are Unix seconds per RFC 7519. Pasting the integer shows whether a token is fresh, replayed, or already expired without spinning up a local debugger.
  • Cross-checking log lines. AWS CloudWatch, Stripe webhooks, and many container runtimes emit milliseconds. Convert the value to ISO before correlating events across services that log in different formats.
  • Sanity-checking client clocks. A user reports a bug at "12:34 local time". Convert the timestamp from their report to UTC, then compare against your server clock to confirm whether their device or your server drifted.

How it works

The converter parses your input as a signed decimal integer, applies the unit (seconds or milliseconds), multiplies into milliseconds, and constructs a JavaScript Date. ECMAScript's Date object is internally a count of milliseconds from the same 1970-01-01T00:00:00Z reference, so the conversion is a single multiplication plus toISOString(). The output is always UTC and always uses the RFC 3339 profile of ISO 8601 with millisecond precision.

  1. Paste the timestamp. Enter a positive or negative integer. Decimal points are accepted. Leading and trailing whitespace is trimmed.
  2. Pick or auto-detect the unit. Leave the unit on auto and the form reads thirteen or more digits as milliseconds, fewer as seconds. Override the choice if you know your source format.
  3. Read the ISO output. The result is an RFC 3339 string ending in "Z" for UTC, with millisecond precision. Copy it straight into a SQL filter, a curl command, or a test fixture.
  4. Verify in your timezone. The ISO string is unambiguous, but humans read local time. Pair the result with a timezone converter to see how the instant maps to New York, London, or Tokyo wall-clock time.

Worked examples

New Year 2024 in seconds

Input 1704067200 with unit auto-detected as seconds (ten digits).

Result: ISO output: 2024-01-01T00:00:00.000Z.

This is the canonical "midnight UTC on 1 January 2024" value seen in many database snapshots.

New Year 2024 in milliseconds

Input 1704067200000 with unit auto-detected as milliseconds (thirteen digits).

Result: ISO output: 2024-01-01T00:00:00.000Z.

Same instant as the seconds example. The length rule routes the larger integer through millisecond parsing.

The epoch itself

Input 0 with unit seconds.

Result: ISO output: 1970-01-01T00:00:00.000Z.

Zero is the reference point of every Unix timestamp on every POSIX-conforming system.

A pre-epoch value

Input -86400 with unit seconds. That is 86,400 seconds before the epoch, or one full day.

Result: ISO output: 1969-12-31T00:00:00.000Z.

Negative timestamps are valid in ECMAScript Date and resolve to instants before 1970-01-01.

Edge cases & gotchas

  • Year 2038 problem. Systems that store the timestamp in a signed 32-bit integer overflow at 2147483647 seconds, which is 2038-01-19T03:14:07Z. This converter uses 64-bit JavaScript numbers, so 2147483648 and beyond resolve correctly. If your source system truncates, you will see a wrap to a negative value near December 1901.
  • Auto-detect ambiguity below 13 digits. A 12-digit value such as 100000000000 parses as seconds (year 5138), even though some APIs emit 12-digit milliseconds. Switch the unit to milliseconds if you know the source uses millisecond precision but predates 2001-09-09.
  • Leap seconds are not represented. Unix time and ECMAScript Date both pretend every day is 86,400 seconds. The 27 leap seconds inserted between 1972 and 2017 are absorbed silently. For sub-second accuracy across leap-second boundaries, consult the spec source rather than an epoch converter.
  • Decimal seconds and rounding. Inputs like 1704067200.5 are accepted and converted to 1704067200500 ms. Sources that emit microseconds or nanoseconds (1704067200000000) trigger millisecond parsing and produce a far-future date; divide by 1000 or 1000000 before pasting.

Frequently asked questions about Unix Timestamp Converter

What is a Unix timestamp?

A Unix timestamp is the count of seconds since 1970-01-01T00:00:00 UTC, ignoring leap seconds. The reference point is defined by IEEE Std 1003.1 (POSIX) and is shared by Linux, macOS, BSDs, and most server runtimes.

Seconds or milliseconds: how do I tell?

Look at the digit count. Ten-digit integers cover roughly 2001 through 2286 in seconds. Thirteen-digit integers cover the same range in milliseconds. The auto-detect rule on this page treats anything with thirteen or more digits as milliseconds.

Why is the output in UTC?

The Unix epoch is defined in UTC, so the unambiguous canonical form of a converted timestamp is also UTC. To see the same instant in a named region, run the ISO string through the timezone converter.

Are negative timestamps valid?

Yes. Negative values represent instants before 1970-01-01. ECMAScript Date supports the full range from roughly 271821 BC to 275760 AD, so any practical pre-epoch value resolves correctly.

Does this handle the Year 2038 rollover?

The converter itself does not truncate at 2147483647. JavaScript numbers are 64-bit, so 2038 and beyond render fine. If your source system stores epoch seconds in a signed 32-bit column, you must widen the column or migrate to a 64-bit type before the rollover.

Why does my ISO output end with "Z"?

The trailing Z is the RFC 3339 abbreviation for "Zulu time", which is identical to UTC offset +00:00. Many parsers accept "Z" and "+00:00" interchangeably.

How do I convert many timestamps at once?

Use the bulk converter to paste a column of values and receive a column of ISO strings. The single-value form on this page is faster for one-off lookups during debugging.

Glossary

Unix epoch
The reference instant 1970-01-01T00:00:00Z from which Unix timestamps are counted. Defined in IEEE Std 1003.1.
ISO 8601
The international standard for representing dates and times as strings, e.g. 2024-01-01T00:00:00.000Z.
RFC 3339
An IETF profile of ISO 8601 used by most internet protocols. Output from this converter conforms to RFC 3339.
Epoch seconds
A timestamp expressed in whole or fractional seconds since the Unix epoch. Common in Postgres, JWT, and shell scripts.
Epoch milliseconds
A timestamp expressed in milliseconds since the Unix epoch. Common in JavaScript Date.now(), Java, AWS, and Stripe APIs.
Year 2038 problem
The overflow point for signed 32-bit Unix-second counters: 2038-01-19T03:14:07Z. Affects legacy filesystems, embedded devices, and old C code.