Unix Timestamp Converter
Convert Unix timestamps (seconds or milliseconds) to human-readable dates across multiple timezones. Also converts dates back to Unix format.
Unix Timestamp Converter
Convert Unix timestamps to human-readable formats β or get the current timestamp now.
How to use the Unix Timestamp Converter
An API response returns "created_at": 1735689600 and you need to know if that date is correct. Paste the number into the input field, or click Use now to grab the current timestamp. The tool instantly shows UTC, ISO 8601, local browser time, relative time ("3 hours ago"), day of week, and the millisecond equivalent. Each row has a copy button for pasting into code or documentation.
The tool auto-detects seconds versus milliseconds: values below 10^12 (like 1735689600) are treated as seconds and multiplied by 1,000 internally; values at or above that threshold (like 1735689600000) are passed directly to the Date constructor. A DevOps engineer correlating logs from three different data centres can paste a timestamp from each, compare the UTC strings, and confirm all three events happened within the same 5-second window β no mental arithmetic required.
Real-World Applications & Use Cases
When an API response contains a field like `"created_at": 1735689600`, engineers need to instantly verify whether that timestamp corresponds to the expected date. Pasting the value here converts it to UTC, ISO 8601, and local time in under a second β far faster than mentally calculating elapsed seconds from the epoch or writing a throwaway script. This is especially valuable when debugging webhook payloads, JWT expiry claims, or database audit logs.
DevOps and SRE teams correlating server logs across data centers in different regions need a canonical, timezone-independent representation. Unix timestamps stored in logs are unambiguous globally, but human-readable UTC and ISO 8601 conversions are needed when writing incident reports or aligning events across AWS CloudWatch, GCP Logging, and local application logs. This tool converts the timestamp and surfaces the UTC string ready to copy into a post-mortem document.
Developers configuring scheduled jobs β cron expressions, AWS EventBridge rules, or database triggers β often need to verify that a computed future Unix timestamp maps to the correct wall-clock time before deploying. Pasting the computed epoch value into this tool and clicking "Use now" for comparison lets engineers confirm the offset is correct without spinning up a REPL or consulting documentation.
Related tools
How the Unix Timestamp Converter works
Seconds vs. milliseconds auto-detection
The converter applies a single threshold rule: if the numeric input is greater than or equal to 1e12 (one trillion), it is treated as milliseconds; otherwise it is treated as seconds and multiplied by 1,000 before being passed to new Date(ms). This boundary was chosen because 1e12 milliseconds corresponds to 9 September 2001 β a date far enough in the past that any real-world timestamp representing a future or recent date in seconds will always be below the threshold, while any millisecond timestamp for a date after 2001 will always be above it. The resulting Date object is validated with isNaN(d.getTime()) before rendering.
Edge cases are handled explicitly: non-numeric input (including empty strings, whitespace, or text) triggers a validation error before any conversion occurs. Floating-point values such as 1735689600.5 are accepted β the parseFloat call preserves sub-second precision, and the resulting ISO 8601 string will include fractional seconds. Negative timestamps (representing dates before 1 January 1970) are valid and convert correctly, since the Date constructor handles negative millisecond values natively. Values outside JavaScript's safe integer range (Number.MAX_SAFE_INTEGER) may produce inaccurate results due to floating-point precision limits, but such values are far beyond any practical timestamp.
Output format reference
new Date(ms)Date.toUTCString() β RFC 7231 format, timezone-independentDate.toISOString() β format: YYYY-MM-DDTHH:mm:ss.sssZDate.toLocaleString() β respects browser IANA timezoneDate.now() diff β minutes, hours, or days from now / agoRelative time calculation
The relative time output computes the difference between the input timestamp and Date.now() in milliseconds, then buckets the result into human-readable labels: under 60,000 ms displays as "just now"; under 3,600,000 ms (one hour) shows rounded minutes; under 86,400,000 ms (one day) shows rounded hours; beyond that shows rounded days. The sign of the difference determines whether the suffix is "from now" or "ago", correctly handling future timestamps such as scheduled event times or token expiry values.
Rounding uses Math.round() rather than truncation, so "3 hr 45 min ago" is displayed instead of "3 hr ago" when the actual difference is 3 hours and 45 minutes. The "just now" threshold of 60 seconds avoids noisy single-second updates when monitoring live timestamps. Because the relative calculation runs on every input event, the output updates in real time as you type β no submit button is required.
Timezone handling and the JavaScript Date API
All internal computation uses UTC. The Date object stores time as a single UTC millisecond value; the UTC and ISO 8601 output fields call toUTCString() and toISOString() respectively, both of which are timezone-independent. The local time output uses toLocaleString() with no explicit timezone argument, which delegates to the browser's IANA timezone setting (typically configured by the operating system). This means the same timestamp will produce different local time strings on machines in different timezones β an intentional design choice that lets you verify how a timestamp appears in your own locale without manual offset arithmetic.
Frequently Asked Questions
How do I know if my timestamp is in seconds or milliseconds?
Timestamps in seconds are typically 10 digits long (e.g. 1735689600 represents a date in 2025). Millisecond timestamps are 13 digits long (e.g. 1735689600000). This tool automatically detects the unit by checking whether the input value exceeds 10ΒΉΒ² β values at or above that threshold are treated as milliseconds, all others as seconds. If you are unsure, compare the resulting UTC date to your expected date to confirm the detection was correct. Most databases, APIs, and logging systems store seconds; JavaScript's <code class="inline-code">Date.now()</code> and many frontend frameworks return milliseconds.
What is the Unix epoch and why does it start in 1970?
The Unix epoch is the reference point for all Unix timestamps: midnight UTC on 1 January 1970 (1970-01-01T00:00:00Z). It was chosen by the developers of Unix at Bell Labs because it was a convenient recent date when the system was being designed in the early 1970s. Every Unix timestamp expresses the number of seconds (or milliseconds) elapsed since that moment, making timestamps a simple, timezone-independent integer that is trivially sortable and comparable across systems. The epoch date also conveniently avoids ambiguous pre-1970 calendar edge cases in most practical applications.
Why does my timestamp show a different local time to UTC?
Local time is rendered using your browser's configured IANA timezone via the JavaScript Intl API. If you are in UTC+10 (Sydney), a timestamp representing 12:00 UTC will display as 22:00 local time. The UTC and ISO 8601 output fields are always timezone-independent and represent the same absolute moment regardless of where in the world the tool is used. If you need to display a specific timezone other than your local one, the ISO 8601 field is the most reliable value to pass to a server-side formatter. You can also override the browser timezone in your operating system settings to preview how the local time output changes.
What is the maximum date this converter supports?
JavaScript's Date object supports values between -8,640,000,000,000,000 ms and +8,640,000,000,000,000 ms, corresponding to approximately 271,821 BCE and 275,760 CE respectively. In practice, any timestamp representing a date in the foreseeable future is well within range. Values outside these bounds cause Date to return NaN, which this tool catches and reports as an out-of-range error. The practical lower bound for most use cases is 0 (1 January 1970), though negative values for pre-1970 dates are valid and convert correctly.
What is ISO 8601 and how does it differ from UTC?
ISO 8601 is an international standard for representing dates and times as strings, produced by the International Organization for Standardization. The format output here β YYYY-MM-DDTHH:mm:ss.sssZ β is the most common machine-readable variant, where the trailing "Z" designates the UTC timezone. UTC (Coordinated Universal Time) is the timekeeping standard itself, not a string format. The ISO 8601 string is the recommended format for storing or transmitting timestamps in JSON APIs because it is unambiguous, sortable as a plain string, and human-readable. Many databases (PostgreSQL, MySQL) and cloud services (AWS, GCP) natively parse ISO 8601 strings into internal timestamp types.
Can I convert a date back to a Unix timestamp?
This tool currently converts from Unix timestamp to human-readable formats only. To go the other direction β from a date string to a Unix timestamp β you can use JavaScript's <code class="inline-code">Date.parse("2025-01-01T00:00:00Z") / 1000</code> in the browser console, or use a dedicated date-to-epoch converter. The division by 1000 converts the millisecond result returned by Date.parse to seconds. Be aware that <code class="inline-code">Date.parse</code> without a timezone suffix interprets the string as local time, so always include "Z" or "+00:00" for UTC-parsed results.
Can I use this tool for timestamps with sub-second precision?
Yes. If you paste a high-precision value such as <code class="inline-code">1735689600.123</code>, the tool passes it through <code class="inline-code">parseFloat</code> and preserves the fractional seconds in the ISO 8601 output (e.g. <code class="inline-code">2025-01-01T00:00:00.123Z</code>). The milliseconds output field will show the truncated millisecond component. Note that the UTC and local time string outputs use second-level precision only, so sub-second detail is only visible in the ISO 8601 and milliseconds fields.
Why do some timestamps appear as "Invalid Date"?
"Invalid Date" occurs when the <code class="inline-code">Date</code> constructor receives a value outside its supported range or a non-numeric input. Common causes include: pasting text instead of a number, entering a value with more than 13 digits (which exceeds the millisecond range), or accidentally including comma separators (e.g. "1,735,689,600"). Remove any non-numeric characters before pasting. If your value is extremely large (e.g. a nanosecond timestamp), divide by 1,000,000,000 to convert to seconds first.