DevKitHub

Programming

Unix Timestamp Converter

Paste a Unix timestamp or an ISO 8601 date. The unit is detected from how many digits it has, and the result is shown in UTC alongside how long ago it was.

Converted — read as seconds

ISO 8601 (UTC)
2025-09-20T12:00:00.000Z
UTC
Sat, 20 Sep 2025 12:00:00 GMT
DateSaturday
2025-09-20
Time (UTC)
12:00:00
Epoch seconds
1758369600
Epoch millis
1758369600000

Every result is in UTC, including a date-time you type without an offset. JavaScript reads the same string as local time, which is why one timestamp can mean two different instants on two machines.

This tool runs entirely in your browser. Your input is never uploaded, stored or logged.

How it works

The unit is inferred rather than asked for, because the number you just pulled out of a log rarely comes labelled. Ten digits is seconds, thirteen is milliseconds, sixteen is microseconds and nineteen is nanoseconds, and every answer states which reading it used so the guess can be checked instead of trusted. Past sixteen digits the value no longer fits exactly in a JavaScript number, so the conversion drops trailing digits off the string rather than dividing — otherwise the millisecond reported would not be the millisecond you typed.

A date-time with no UTC offset is read as UTC. JavaScript does something stranger: new Date("2026-09-20T05:30:00") is interpreted in the local time zone, while new Date("2026-09-20") is interpreted as UTC. The same string therefore means two different instants depending on which line of the specification applies and where the machine is, which is a genuinely common source of off-by-five-and-a-half-hours bugs. Pinning everything to UTC is the only way this tool can give a browser in Mumbai and a server in Frankfurt the same answer.

Dates that do not exist are rejected instead of being silently moved. Date.parse("2026-02-29") does not fail — it returns 1 March, because 2026 is not a leap year and the parser rolls the surplus day forward. Answering a question about a different date than the one that was typed is worse than refusing, so the day is checked against the real length of that month first. Formats outside ISO 8601 are also refused, because parsing them is explicitly implementation-defined and browsers do not agree with each other.

Common problems

Every example below is run against this tool in our test suite, so what it says here is what the tool actually does.

2026-02-29 is not a real date: 2026 is not a leap year, so February has 28 days.

2026-02-29
Why:
A date generated by arithmetic that added a year to 2024-02-29 without checking whether the result exists.
Fix:
Use 2026-02-28 or 2026-03-01, and fix the arithmetic to clamp to the end of the month.

2026-04-31 is not a real date: that month has 30 days.

2026-04-31
Why:
Day 31 in a 30-day month, usually from a hand-built date string or a loop that assumes every month has 31 days.
Fix:
Use the last real day of the month. JavaScript would have silently read this as 1 May.

Not a Unix timestamp or an ISO 8601 date.

Sep 20 2026
Why:
Locale-style dates are rejected on purpose: the specification leaves their parsing up to each engine, so Node and Chrome can disagree about the same string.
Fix:
Convert it to ISO 8601 first: 2026-09-20, optionally with a time and an offset.

A date in 1970 when you expected today.

Why:
A millisecond timestamp was handed to something expecting seconds, or vice versa — a factor of 1000 puts 2026 back near the epoch.
Fix:
Check the digit count: 10 digits is seconds, 13 is milliseconds. The result here always says which it used.

Frequently asked questions

What is a Unix timestamp?
The number of seconds elapsed since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. It is the most common way to store an instant because it is a single number with no time zone attached.
How do I tell seconds from milliseconds?
Count the digits. A present-day timestamp in seconds has 10 digits; in milliseconds it has 13. If a date comes out in 1970 you passed milliseconds to something expecting seconds, and if it comes out in the year 56000 you did the reverse.
Why is everything shown in UTC?
So the answer does not depend on where you are. A date-time with no offset is read as UTC rather than local time, which is the opposite of what new Date() does with the same string, and the reason two machines can disagree about one timestamp.
What is the year 2038 problem?
Systems that store the timestamp in a signed 32-bit integer overflow on 19 January 2038 and wrap to 1901. Anything storing time in a 64-bit integer, which includes JavaScript numbers up to 2^53 milliseconds, is unaffected.

Read more about this

Last updated