Timestamp Converter
Convert between Unix timestamps and human-readable dates. Supports seconds and milliseconds.
Updated July 11, 2026
100% Private & Secure
This tool runs in your browser.
Your data is never uploaded or stored.
Unix Timestamp → Date
Date → Unix Timestamp
How to use
- 1
Enter a Unix timestamp or pick a date.
- 2
The tool converts it automatically.
- 3
Copy the result.
When to use it
Reading API response fields
OAuth tokens, JWT exp/iat claims, database created_at columns, and log lines all quote epoch seconds. Pasting 1735689600 and seeing 2025-01-01T00:00:00Z turns an opaque integer into a date you can reason about.
Scheduling tasks and TTLs
Cache expiry, signed-URL validity, and cron triggers are all expressed as "now plus N seconds." Converting between a target wall-clock time and epoch lets you verify that a TTL of 3600 actually lands where you expect across timezones.
Cross-checking millisecond vs second timestamps
JavaScript's Date.now() returns milliseconds; Java's Instant.now().getEpochSecond() returns seconds. Mixing them up shifts a date by 1970 or by the year 5138. A converter that handles both units catches the mismatch instantly.
Validating logs from different regions
A distributed system logs events from servers in UTC, PST, and JST. Converting every epoch value to your local zone (or to UTC) makes it possible to build a single ordered timeline and find the request that triggered a cascade.
How it works
Unix epoch: seconds since 1970-01-01 UTC
A Unix timestamp counts the seconds elapsed since the epoch — midnight UTC on 1 January 1970 — as defined by POSIX time. It is timezone-agnostic by construction: the same instant has one timestamp everywhere on Earth. Local time is applied only when the value is rendered for humans.
Two unit conventions coexist and are the single largest source of bugs. Seconds are the POSIX default (shell date +%s, Python time.time() on most systems, JWT claims). Milliseconds dominate the browser and JVM (Date.now(), System.currentTimeMillis(), Java/JavaScript Date). Always confirm which unit a value is in before doing arithmetic.
-
0-> 1970-01-01T00:00:00Z (the epoch) -
1735689600-> 2025-01-01T00:00:00Z (seconds) -
1735689600000-> same instant, expressed in milliseconds - JavaScript
Date.now()returns ms; divide by 1000 to compare with a POSIX value
ISO 8601 and RFC 3339: human-readable, unambiguous
For interchange, the canonical string format is RFC 3339, a strict profile of ISO 8601. Its grammar is YYYY-MM-DDThh:mm:ss[Z|±hh:mm] — a full date, the letter T as separator, full time, and a mandatory timezone designator.
The timezone suffix is what makes the format safe. 2025-01-15T13:45:30Z (the Z means UTC) and 2025-01-15T08:45:30-05:00 denote the same instant. Parsing either with a compliant parser yields one unambiguous timestamp, unlike naive formats such as 01/15/2025 that Americans and Europeans read differently.
// Seconds -> ISO 8601 (UTC)
new Date(sec * 1000).toISOString();
// "2025-01-01T00:00:00.000Z"
// ISO 8601 -> seconds
Math.floor(Date.parse("2025-01-01T00:00:00Z") / 1000);
// 1735689600The Year 2038 problem
Systems that store Unix time as a signed 32-bit integer hit a hard limit at 03:14:08 UTC on 19 January 2038. At that moment the counter reaches its maximum of 2,147,483,647 seconds since the epoch and overflows, wrapping to a negative number that systems interpret as 13 December 1901.
The fix is structural, not arithmetic: migrate to a 64-bit time_t, which on modern 64-bit operating systems has already happened. The exposure lives in 32-bit embedded devices, legacy databases with INT32 timestamp columns, on-wire protocols with fixed-width fields, and file formats baked into long-lived storage. Auditing those — not the server clock — is where Y2038 work actually happens.
Common mistakes & edge cases
A timestamp renders as a date in 1970 or the year 50,000+
Unit mismatch. JavaScript Date expects milliseconds; a seconds value is treated as 1970. Multiply seconds by 1000 before constructing a Date, or divide ms by 1000 before sending to a POSIX API.
A date is off by hours across servers in different regions
You are mixing local time and UTC. Store and compare epoch seconds or ISO 8601 with a Z/offset suffix; apply local timezone only at the presentation layer.
Date.parse returns NaN for a "valid-looking" string
Pre-ES2015 browsers did not reliably parse ISO strings without a timezone. Always emit the full RFC 3339 form with a Z or offset, and use a library (or Temporal) for non-UTC zones.
Integer overflow on a 32-bit system around 2038
Move storage and transport off INT32. Use a 64-bit integer or ISO 8601 string for any timestamp that must remain valid past January 2038, including long-lived records and binary protocols.