JavaScript Timestamp Converter – Date.now() to Date

How to use JavaScript Timestamp Converter

Paste a timestamp or a date string, or press “Use this value” for the current time.
Leave the unit on auto-detect, or state whether a number is in milliseconds or seconds.
Choose a time zone and locale to preview formatted dates.
Copy any result, or the code snippet at the bottom.

JavaScript Timestamp Converter features

Code beside each result

Each row shows a JavaScript expression and what it returns for your value.

Milliseconds and seconds

Detects 13-digit JavaScript timestamps and 10-digit Unix timestamps, and shows the conversion.

Parsing explained

Tells you how a date string was interpreted: as UTC, as local time, or by browser-specific rules.

Time zones and locales

Formats with toLocaleString and Intl.DateTimeFormat for any IANA time zone.

Date from parts

Builds new Date(year, month, day…) and Date.UTC(…), with the zero-based month handled for you.

Live Date.now()

The current timestamp updates every second.

When to use JavaScript Timestamp Converter

Decoding a timestamp from a log, a token or an API response while debugging.
Finding the right method to format a date for users in another time zone.
Converting between the seconds a backend sends and the milliseconds JavaScript expects.
Checking how a date string will be parsed before relying on it.

JavaScript Timestamp Converter FAQ

Why does JavaScript use milliseconds?

A Date stores the number of milliseconds since 1 January 1970 UTC. Most other systems, including Unix, PHP, Python and many APIs, count seconds. Multiply seconds by 1000 before passing them to new Date(), and divide getTime() by 1000 when sending a timestamp back.

How is this different from the Timestamp Converter?

The general converter turns Unix timestamps into dates and back, for any context. This one is for JavaScript work: it shows the Date methods and Intl calls with their actual output, explains string parsing rules, and generates code.

Why is my date one day off?

Usually because of parsing. new Date("2026-01-15") is read as midnight UTC. In a time zone west of Greenwich that is still the evening of the 14th in local time. Add a time and an offset to the string, or build the date from parts.

Why is the month wrong by one?

In the Date constructor and in getMonth(), months run from 0 (January) to 11 (December). Days and years are not shifted. The “Build a Date from parts” section subtracts one for you and shows the resulting code.

Which format should I store?

The millisecond number or the ISO 8601 string from toISOString(). Both are unambiguous and independent of time zone. Format for display only at the last moment, with toLocaleString or Intl.DateTimeFormat.

What is the valid range of a Date?

Exactly 100,000,000 days either side of 1 January 1970, which is ±8,640,000,000,000,000 milliseconds, roughly the years −271821 to 275760. Beyond that, the Date is invalid.

Timestamp Converter Translate between epoch time and readable dates in both directions. The unit is… JavaScript Code Runner Write or paste JavaScript, press Run and read the console output next to your… Age Calculator Enter a date of birth to get an exact age in years, months and days, on today's… Time Zone Converter Pick a date and time in one place and see what it is everywhere else. Add as many… Cron Expression Generator Create a cron schedule without memorising the syntax, or paste an existing… JavaScript Formatter Turn a wall of minified JavaScript into properly indented code you can read and…

How the JavaScript Date object really works

A JavaScript Date is a single number in a wrapper: the count of milliseconds since the start of 1970 in UTC. It holds no time zone and no format. Everything else, the year, the weekday, the text you see when you print it, is computed from that number on request. Methods such as getHours() and toString() compute in the time zone of the device, their UTC counterparts such as getUTCHours() and toISOString() compute in UTC, and the locale methods accept a time zone explicitly.

This explains most surprises. Two users in different countries who run the same code on the same timestamp see different hours, correctly, because each sees local time. A date sent as a formatted local string loses its meaning on arrival. A timestamp or an ISO string with Z does not. The reliable rule is to store and transmit the number or the ISO string, and to convert to local, human-readable text only when showing it.

Parsing is the other source of trouble. The language specification only guarantees the ISO 8601 format, and even there it has a quirk: a date without a time is treated as UTC, while a date with a time but no offset is treated as local. Other formats, such as “01/02/2026” or “Jan 2, 2026”, are left to each engine, and results can differ. When input comes from users, parse the pieces yourself and construct the Date from numbers.

For output, the Intl API has largely replaced hand-written formatting. Intl.DateTimeFormat produces dates in the conventions of any locale and any time zone from one line of code, and Intl.RelativeTimeFormat produces phrases such as “in 3 days”. Date arithmetic is done on the millisecond value. Adding 24 hours is simple addition; adding “one month” is not, because months differ in length, which is where a library or the newer Temporal API becomes worthwhile.

Build a Date from parts