Timestamp Converter

A Unix timestamp (also called an epoch timestamp or POSIX time) is a single integer that represents a specific point in time as the number of seconds — or milliseconds — elapsed since the Unix epoch: midnight on January 1, 1970, in Coordinated Universal Time (UTC). This universal reference point was chosen when the Unix operating system was being developed in the late 1960s and early 1970s, and it has since become the most widely adopted time representation in computing.

Because a Unix timestamp is just a number, it is compact, unambiguous, and completely independent of timezones, daylight saving rules, locale settings, or calendar systems. A timestamp of 1700000000 means exactly the same point in history on every computer in the world, whether it is displayed as "November 14, 2023, 10:13 PM UTC" to one user or "November 15, 2023, 8:13 AM JST" to another.

Unix timestamps appear in virtually every modern technology stack: database columns, HTTP headers, JWT tokens, log files, file system metadata, API responses, and cryptographic certificates. Understanding how to convert between a raw timestamp and a human-readable date is a fundamental skill for developers, sysadmins, data analysts, and anyone who works with software systems.

This free online timestamp converter handles both directions instantly. Paste any Unix timestamp in seconds or milliseconds and see the equivalent ISO 8601 string, UTC string, your local time, relative time, day of the week, day of the year, and ISO week number. Or pick a date and time to get the corresponding Unix timestamp values you can copy straight into your code.

The two most common flavors of Unix timestamp are second-precision and millisecond-precision. Knowing which one you are dealing with is critical before converting, because treating a millisecond timestamp as seconds will land you roughly 31,000 years in the future, and treating a second timestamp as milliseconds will produce a date somewhere in the early 1970s.

A quick heuristic: if your timestamp has 10 digits (e.g. 1700000000), it is almost certainly in seconds. If it has 13 digits (e.g. 1700000000000), it is in milliseconds. This rule holds true for all dates in the roughly 1970–2286 window.

This converter supports both units via the Seconds / Milliseconds toggle. Simply select the correct unit before pasting your value and the conversion will be precise regardless of which format your source system uses.

Converting a Unix timestamp to a human-readable date follows a straightforward sequence. The converter first normalizes your input to milliseconds (multiplying by 1000 if you selected the Seconds unit), then passes that value into JavaScript's built-in new Date(ms) constructor. From the resulting Date object, it derives every output format simultaneously:

• Local Time — the date and time displayed in the visitor's own browser timezone, using the device's locale for formatting.
• UTC — the date and time in Coordinated Universal Time, independent of any local offset.
• ISO 8601 — the standardized machine-readable format YYYY-MM-DDTHH:mm:ss.sssZ, universally accepted by APIs and databases.
• Relative time — a human-friendly approximation such as "3 days ago" or "in 2 hours," calculated by comparing the target date to Date.now().
• Day of week — the full name of the weekday (e.g. Wednesday).
• Day of year — computed as Math.floor((date − new Date(year, 0, 0)) / 86400000), counting days elapsed since December 31 of the previous year.
• ISO week number — the ISO 8601 week of the year (1–53), using the standard algorithm that anchors week 1 to the week containing the first Thursday of the year.

All these values update immediately as you type, making the tool ideal for quick lookups during debugging sessions, data audits, or API integration work.

The reverse direction — converting a calendar date and time back to a Unix timestamp — is equally useful when you need to store or transmit a date in a system that expects a numeric value. Enter a date using the date picker and a time using the time input (defaulting to midnight if left blank). The converter assembles a combined string in the format YYYY-MM-DDTHH:mm:ss and passes it to new Date().

Because this string contains no timezone offset, JavaScript interprets it as local time — the timezone of the device running the browser. The resulting Date object is then converted to both second-precision and millisecond-precision Unix timestamps using:

• seconds = Math.floor(date.getTime() / 1000)
• milliseconds = date.getTime()

Both values are displayed with one-click copy buttons so you can paste them directly into code, SQL queries, configuration files, or API request bodies without transcription errors.

One important nuance: if you need the timestamp for a specific UTC moment rather than a local-time moment, append the UTC offset manually to your date string (e.g. treat the time as UTC by setting your system clock to UTC, or remember that the converter reflects your local offset). This is a deliberate behavior — most use cases involve scheduling or logging events in the user's own timezone, so local-time interpretation is the safer default.

The choice of January 1, 1970 as the epoch origin was largely arbitrary — it was simply a round date that predated the first Unix systems by a few years, giving early developers a comfortable buffer for historical records. The date has since become a cultural and technical reference point in computing, immortalized in jokes about 1970 dates appearing in applications whenever a zero timestamp is accidentally displayed as a human date.

More seriously, the Year 2038 Problem (sometimes called Y2K38) is a real concern for legacy systems. Many older 32-bit systems store timestamps as a signed 32-bit integer, which can hold a maximum value of 2,147,483,647. That value corresponds to January 19, 2038, at 03:14:07 UTC. One second later, the integer overflows to a large negative number, typically interpreted as December 13, 1901. Modern 64-bit systems are not affected — a signed 64-bit timestamp can represent dates hundreds of millions of years in the past and future — but embedded systems, databases with legacy schemas, and old firmware may still require careful migration planning.

When exchanging timestamps between systems, the representation format is just as important as the numeric value. Three formats dominate modern software:

• Unix timestamp (integer) — the most compact and unambiguous form; no parsing ambiguity; ideal for storage and arithmetic but unreadable by humans.
• ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ) — the international standard for date/time strings; the trailing Z indicates UTC; sortable as a plain string; accepted by virtually every modern programming language, database, and API.
• RFC 2822 / UTC string — the format used in HTTP headers and email (Thu, 14 Nov 2023 22:13:20 GMT); human-readable but less compact.

When in doubt, store and transmit dates as Unix timestamps (integers) or ISO 8601 UTC strings. Both eliminate timezone ambiguity entirely. Avoid storing dates as locale-formatted strings (e.g. "11/14/2023") in databases or APIs — the month/day order differs between regions and creates parsing bugs that are notoriously difficult to trace.

This converter displays all three representations so you can choose whichever format your target system requires, then copy it with one click.