Unix Timestamp Converter

A Unix timestamp counts the seconds since the Unix epoch — midnight UTC on 1 January 1970. It is the most common way programs store a moment in time because it is a single number with no timezone attached. This free converter turns that number into a readable date in any timezone, and turns dates back into epoch values.

When you need this

You encounter Unix timestamps in API responses, database records, log files, JWT expiry fields, and almost any system where two machines exchange time. Raw values like 1749225000 are not human-readable, which is where the converter comes in. The reverse direction — turning a date like 2026-06-06 14:30 into an epoch — is equally common when you need to build a query or set an expiry.

Epoch arithmetic, precisely

When you paste a timestamp, the tool first decides whether it is in seconds or milliseconds. It does this by magnitude: a value of 13 or more digits is treated as milliseconds (the unit JavaScript’s Date uses internally), and a shorter value is treated as seconds and multiplied by 1000.

It then builds a JavaScript Date from those milliseconds and formats it two ways:

• ISO 8601 in UTC, for example 2026-06-06T14:30:00.000Z, produced by toISOString().
• A locale-formatted string in your chosen IANA timezone, produced by the Intl.DateTimeFormat API, which applies the correct UTC offset and daylight-saving rules for that zone and date.

The reverse field takes a date and time and returns the matching epoch in both seconds and milliseconds.

Worked example

Suppose an API returns created_at: 1717679400. Paste it into the converter:

• Interpreted as: seconds (10 digits)
• UTC (ISO 8601): 2024-06-06T13:30:00.000Z
• Europe/London: 2024-06-06 14:30:00 BST (UTC+1 in summer)
• America/New_York: 2024-06-06 09:30:00 EDT (UTC-4 in summer)

The underlying instant is the same in every timezone — only the display changes.

Now reverse it: enter 2024-06-06 14:30 in London time and the tool returns 1717679400 in seconds and 1717679400000 in milliseconds, ready to paste into a query filter or expiry setting.

Seconds vs milliseconds — why it matters

The most common source of confusion with timestamps is the unit. A value of 1717679400 is June 2024 in seconds; the same digits with three zeros appended (1717679400000) is the same moment in milliseconds. Accidentally treating a millisecond timestamp as seconds puts you in the year 56468, and treating a second timestamp as milliseconds puts you about 27 minutes past the epoch (January 1970). The Interpreted as row in the result shows which the tool detected so you can catch mismatches immediately.

Tips and notes

• A live clock at the top shows the current Unix time so you can grab “now” instantly.
• Timestamps are UTC by definition; the timezone selector only changes how the same instant is displayed, never the underlying value.
• When working with JWT tokens, the exp, iat, and nbf fields are always Unix seconds — paste them here to confirm expiry in human-readable form.
• Everything is computed locally with the browser’s standard date APIs, so it is safe to use with internal or sensitive timestamps.

Time zones: the conversion that isn’t one

An epoch timestamp has no time zone — it counts seconds since 1970-01-01T00:00:00 UTC, full stop. The time zone enters only when you format it for humans. That is why the same timestamp renders as different wall-clock times in London and Tokyo, and why storing local wall-clock strings in databases causes the classic double-conversion bugs. The robust pattern: store and transmit epoch values or ISO 8601 strings with explicit offsets (2026-07-02T09:00:00Z), convert to local time only at the display edge, and never at both ends.

Leap seconds and other honesty footnotes

Unix time pretends every day has exactly 86,400 seconds. Reality inserts occasional leap seconds (coordinated by the IERS), which Unix time absorbs by repeating or smearing a second rather than counting it — so the epoch count is not literally the number of SI seconds elapsed. For scheduling, logging and expiry logic this never matters; for sub-second scientific timing it does, and specialised time scales (TAI, GPS time) exist for that. Two more practical notes: epoch values are identical across all systems regardless of locale (their great virtue), and the formatting standard worth adopting everywhere else is ISO 8601, which sorts lexicographically and cannot be misread as US-vs-European date order.

A final defensive habit: when a converted date looks plausible but wrong by exactly your timezone offset, the bug is a local-time formatting applied twice — once by the producer and once by your display layer. Reproduce the value in UTC first, then convert to local; if the UTC rendering is correct, the data is fine and only the display is lying.

Keep a couple of anchor values memorised for sanity checks: 0 is the 1970 epoch itself, 1000000000 landed in September 2001, and 2000000000 falls in May 2033 — any “current” timestamp far outside the 1.7–2.0 billion range is in the wrong unit or the wrong era.