ToolNestHow to Convert a Unix Timestamp to a Date in JavaScript
To convert a Unix timestamp to a date in JavaScript, multiply the timestamp by 1000 and pass it to the Date constructor: new Date(1761112800 * 1000) gives the date for that Unix time. The multiplication matters because Unix timestamps count seconds, while JavaScript dates count milliseconds. Convert any timestamp instantly with our free Unix timestamp converter.
The Core Conversion: Multiply by 1000
A Unix timestamp counts seconds since January 1, 1970 (the Unix epoch), while JavaScript's Date counts milliseconds since the same epoch. That factor-of-1000 difference is the entire conversion: new Date(unixSeconds * 1000). For the timestamp 1761112800, multiplying by 1000 gives 1761112800000 milliseconds, and new Date(1761112800000) returns the corresponding date and time. Skip the multiplication and JavaScript will interpret 1761112800 as milliseconds — about 21 days after the epoch, in January 1970 — which is the single most common bug in timestamp code and the first thing to check whenever a date comes out in 1970. The reverse conversion divides by 1000: Math.floor(Date.now() / 1000) gives the current Unix timestamp in seconds, and Math.floor(new Date('2026-10-21').getTime() / 1000) converts a date string back to seconds. For a quick check without writing code, our Unix timestamp converter shows both the seconds and milliseconds forms side by side, so you can confirm which one your data actually contains before you write a line of JavaScript.
10 Digits or 13? Detecting Seconds vs Milliseconds
Real-world timestamps arrive in both units, and guessing wrong shifts dates by a factor of 1000 in either direction. The reliable tell is digit length: a current Unix timestamp in seconds has 10 digits (1761112800), while the same moment in milliseconds has 13 digits (1761112800000). A defensive conversion handles both: if the value is greater than 9999999999 (more than 10 digits), treat it as milliseconds and pass it directly to new Date; otherwise multiply by 1000 first. In code, that is: const ms = ts > 9999999999 ? ts : ts * 1000; const date = new Date(ms). Two cautions: timestamps before September 2001 have only 9 digits in seconds, so the digit test still works (9 digits is under the threshold, correctly multiplied), and timestamps stored as strings need Number(ts) before the comparison, or JavaScript will compare them lexicographically and misclassify. APIs are inconsistent about which unit they send — some send seconds, some milliseconds, and a few send microseconds (16 digits) — so never assume: log one raw value, count its digits, and let the data tell you. The same seconds-versus-milliseconds discipline appears in our Unix timestamp to date in Python guide, where datetime.fromtimestamp expects seconds just like the manual JavaScript conversion.
Formatting the Result: toISOString vs toLocaleString
Getting a Date object is only half the job; displaying it correctly is the other half, and the two built-in formatters answer different questions. toISOString() returns UTC in a fixed format like 2026-10-21T12:00:00.000Z, which is ideal for APIs, logs, and databases because it never depends on the reader's time zone. toLocaleString() returns the date in the user's local time zone and locale format, which is ideal for user interfaces — the same instant shows as a morning time in Los Angeles and an evening time in Berlin, and both are correct. The bug to avoid is mixing them: storing toLocaleString output in a database bakes one user's time zone into shared data, while showing toISOString output to end users confuses everyone outside UTC. The rule is: store and transmit UTC (toISOString or the raw timestamp), display local (toLocaleString with explicit options like hour, minute, and timeZoneName when the zone matters). For spreadsheet-based timestamp work rather than code, our Unix timestamp to date in Excel guide covers the equivalent UTC-and-local handling, and for the reverse direction — turning a date into a timestamp — our date to Unix timestamp guide walks through the online method.
Time Zones, Daylight Saving, and Validation
Unix timestamps themselves have no time zone — they are absolute instants — and time zones only enter when a Date is formatted for display. That is a feature, not a bug: the same timestamp means the same instant everywhere, and local formatting translates it per viewer. Daylight saving time is handled automatically by the Date object for local formatting, so a timestamp from July and one from January in the same zone display with the correct offset each, without manual adjustment. The pitfalls are at the edges: a timestamp of 0 is exactly 1970-01-01T00:00:00Z, so a date of January 1970 in your output usually means a missing or zero timestamp, not a real event; a negative timestamp means a date before 1970, which is valid but rare in web data; and a timestamp far in the future (beyond the year 2038 for 32-bit systems) can overflow older backends, though JavaScript's millisecond numbers handle dates safely for hundreds of thousands of years. Validate before converting: check that the value is a finite number, that it falls in a plausible range for your data (for most web data, between 0 and about 4102444800, the year 2100), and that the resulting Date is not Invalid Date — new Date(NaN) silently produces one, and formatting it prints Invalid Date rather than throwing. A one-line guard, if (!Number.isFinite(ts)) throw new Error('bad timestamp'), catches the worst cases before they reach your users. When a timestamp needs converting once rather than in code, the Unix timestamp converter and the minutes to hours converter handle the surrounding time arithmetic without any code at all.