Unix Timestamp Converter

Paste an epoch value or a date string and get every common representation at once: seconds, milliseconds, UTC, ISO 8601, and your local timezone. Ten-digit values are read as seconds and thirteen-digit values as milliseconds, so log entries from either convention convert without you counting digits. Typing now converts the current moment.

How to convert a timestamp

1. Paste one value into Timestamp or date in. It can be a whole-number epoch value (seconds or milliseconds, negative allowed), a date string such as 2026-01-01T00:00:00Z, or the word now.
2. Press Convert.
3. Read Conversion out. For a number, the first line tells you whether it was read as seconds or milliseconds. The five lines after that give Unix seconds, Unix milliseconds, a UTC date, an ISO 8601 string, and the same moment in your computer's timezone.
4. Press Copy result for the whole block, or select just the line you need. Clear empties both boxes.

What a Unix timestamp is

A Unix timestamp counts seconds since the Unix epoch, midnight UTC on January 1, 1970. The value 0 is that instant, 86400 is exactly one day later, and negative values are dates before 1970. The count has no timezone: the same timestamp names the same instant in Tokyo and in Toronto, which is why logs and databases store time this way and convert only for display.

Two details catch people out:

• Leap seconds are not counted. The POSIX definition of seconds since the epoch treats every day as exactly 86,400 seconds. Subtracting two timestamps therefore gives calendar time, which can differ by a few seconds from the physical time that elapsed across leap seconds. JavaScript dates follow the same rule.
• Seconds versus milliseconds. C, Python's time.time(), PostgreSQL's extract(epoch ...), and most Unix tools use seconds. JavaScript's Date.now() and Java's System.currentTimeMillis() use milliseconds. Current dates are 10 digits in seconds and 13 digits in milliseconds. Mixing them up gives dates in 1970 or tens of thousands of years in the future.

The year 2038 problem comes from storing seconds in a signed 32-bit integer. The largest value, 2147483647, is 2038-01-19T03:14:07Z, and one second later such a counter wraps to a negative number. Paste that value here to see the exact moment.

A worked example

Input:

1767225600

Output for a browser set to US Eastern time:

Interpreted as: seconds
Unix seconds:  1767225600
Unix millis:   1767225600000
UTC:           Thu, 01 Jan 2026 00:00:00 GMT
ISO 8601:      2026-01-01T00:00:00.000Z
Your timezone: Wed Dec 31 2025 19:00:00 GMT-0500 (Eastern Standard Time)

New Year 2026 in UTC is still the evening of December 31 in New York. When someone reports that a midnight job "ran on the wrong day", this five-hour offset is usually the reason. The last line's format comes from your browser, so its wording can vary.

Date strings need one more rule. Under the JavaScript date parsing rules, a date with no time, like 2026-01-01, is read as midnight UTC, while a date and time with no offset, like 2026-01-01T00:00, is read as midnight in your local timezone. In US Eastern time the first converts to 1767225600 and the second to 1767243600, five hours apart. Add Z or an explicit offset such as -05:00 whenever the zone matters.

Common problems and how to fix them

A date comes out around 57,000 years in the future

The value is in microseconds, 16 digits for current dates, a unit some databases, analytics exports, and tracing systems use. The tool reads anything above 99,999,999,999 as milliseconds, so microseconds land far in the future. Remove the last three digits and convert again.

"Out-of-range timestamp." for a 19-digit value

That is a nanosecond timestamp, common in Go and in systems like InfluxDB and OpenTelemetry. It is beyond the range a JavaScript date can hold. Remove the last six digits to get milliseconds.

A millisecond value from the early 1970s is read as seconds

The seconds-or-milliseconds decision is based only on size. A millisecond timestamp below 100,000,000,000, meaning any moment before March 3, 1973, is interpreted as seconds and lands decades later. If the output line says seconds but you know the source uses milliseconds, divide by 1000 yourself and paste the result.

A value with a decimal point does not convert

Only whole numbers are treated as timestamps. Values like 1767225600.5, which some languages print for fractional seconds, fall through to date parsing, which rejects them or, depending on the browser, may return a meaningless date. Delete the decimal part, or multiply by 1000 and round to get milliseconds.

A date string converts to an unexpected time

Formats other than ISO 8601, such as 01/02/2026 or 2 Jan 2026 10:00, are parsed by rules each browser sets for itself, usually in local time and with US month-first order. Rewrite the value as ISO 8601 with an explicit offset for a result you can trust.

Related tasks

To see when a scheduled job will next fire, use the cron expression parser. If the timestamp sits inside a login token, the JWT decoder shows its exp and iat claims.

Questions this tool gets asked

How does it tell seconds from milliseconds?

Values above 99,999,999,999 are treated as milliseconds. In practice, 10-digit timestamps are seconds and 13-digit timestamps are milliseconds, and the output states which interpretation was used.

What date formats can I paste?

ISO 8601 strings like 2026-01-01T00:00:00Z are the reliable choice. Most browser-parseable formats also work, and the word now converts the current time.

Is the local time based on my machine?

Yes. The local rendering uses your operating system's timezone, computed entirely in your browser.

Related tools

• cron explainCrontab syntax explained, with the next five real run times.
• regex testPattern on line 1, text below - every match and group listed.
• uuid v4Cryptographically random UUID v4s, one or a thousand at a time.
• password genCrypto-random passwords with the entropy math shown.