English
Convert between Unix timestamps, ISO 8601, UTC, and local time.
Last updated
177723918917772391890002026-04-26T21:33:09.000Z2026-04-26 21:33:09Sun, 26 Apr 2026 21:33:09 GMTA Unix timestamp converter turns *epoch time* — a single number representing a moment in history — into human-readable dates, and converts dates back into timestamps. Developers see timestamps everywhere: database columns, log lines, API responses, analytics events, JWT exp claims, scheduler triggers, and cache expiration headers.
The core idea is simple: computers store time as a number (seconds or milliseconds since 1970-01-01 00:00:00 UTC), but humans need calendars, time zones, and readable formats. Converting between the two is one of the most common debugging tasks in any web or mobile app.
The most confusing part is *units*. POSIX and most backend languages use seconds. JavaScript, Java, and many message brokers use milliseconds. Some metrics systems use microseconds or nanoseconds. A 10-digit number is almost always seconds; a 13-digit number is almost always milliseconds.
1970-01-01 00:00:00 UTC).2026-04-25T12:00:00Z) is a portable text format. The trailing Z (or +00:00) means UTC; an offset like +02:00 means a local time that is 2 hours ahead of UTC.Paste a number (seconds or milliseconds) or a date string. The converter auto-detects the format based on length and shape.
Toggle seconds vs milliseconds if the auto-detection guesses wrong — a 10-digit number is seconds, a 13-digit number is milliseconds.
The output shows ISO 8601 in UTC, your local time, and a human-readable relative phrase (3 hours ago, in 2 days).
Copy the timestamp, the ISO string, or the local time directly. Useful when filling in a JWT exp, a database row, or a log query.
The formats you'll see most often when working with dates and times in code. ISO 8601 is also profiled by the IETF as RFC 3339 for use in protocols.
| Format | Example | Where you see it |
|---|---|---|
| Unix seconds | 1777118400 | Backend logs, JWT exp, POSIX time(), Redis |
| Unix milliseconds | 1777118400000 | JavaScript Date.now(), Java System.currentTimeMillis() |
| ISO 8601 UTC | 2026-04-25T12:00:00Z | REST APIs, JSON, GraphQL, log files |
| ISO 8601 with offset | 2026-04-25T14:00:00+02:00 | User-facing scheduling, calendar invites |
| RFC 2822 | Sat, 25 Apr 2026 12:00:00 GMT | Email headers, HTTP Date and Last-Modified |
| Date only | 2026-04-25 | Birthdays, holidays — no time-zone meaning |
1777118400
1777118400000
Both values describe the same moment if the first is interpreted as seconds and the second as milliseconds. Mixing them up is the most common timestamp bug.
{ "id": 42, "createdAt": 1777118400, "expiresAt": 1777204800}Convert each value before assuming whether it is in the past or future. Most JSON APIs use Unix seconds, but always check the docs — JavaScript-heavy backends often emit milliseconds.
2026-04-25T12:00:00Z
2026-04-25T14:00:00+02:00
These two strings represent the *same instant*. Always store moments in UTC; format to local time only at display time.
1700000000 read as seconds is November 2023, but read as milliseconds it's January 1970.'2026-04-25') instead of comparing timestamps. Two valid ISO strings can describe the same moment in different formats.1970-01-01 00:00:00 UTC. It's a single number that represents a specific moment in time, independent of any time zone.Date.now() returns milliseconds; most backends return seconds.Date object stores timestamps as milliseconds since the Unix epoch — that's the value Date.now() and new Date().getTime() return. It gives more precision than seconds, but it's a frequent source of off-by-1000 bugs when interfacing with other languages.new Date(...) in JavaScript, or use datetime.fromtimestamp(...) in Python. Or paste it into a Unix timestamp converter for a one-click result.2038-01-19 — the so-called Year 2038 problem. Modern languages and databases store timestamps as 64-bit integers, which extends the safe range by hundreds of billions of years.