Paste an ISO 8601 date to get Unix seconds: 2026-01-01T00:00:00Z becomes 1767225600. The next row is milliseconds (seconds × 1000) for JavaScript. A date-only string parses as UTC midnight; a date-with-time string without a zone suffix parses in your local timezone. Append Z to remove the ambiguity. Conversion stays in this tab.
Starting clock
Starting clock
1767225600
1767225600000
2026-01-01T00:00:00.000Z
Waiting for input
Waiting for input
Runs in this tab · nothing is uploaded · Verify in 10 seconds →
An ISO 8601 date converts to the count of seconds since 1970-01-01T00:00:00 UTC: 2026-01-01T00:00:00Z becomes 1767225600. Paste a date below; the output is Unix seconds (the unit expected by most APIs, databases and JWT claims) with JavaScript's milliseconds (seconds × 1000) on the next row.
Timezone handling follows the ECMAScript standard exactly, and it is asymmetric: a date-only string (2026-01-01) parses as UTC midnight, but a date-with-time string without a zone suffix (2026-01-01T09:00) parses in your local timezone. One suffix character (Z, or an explicit offset like +02:00) removes the entire class of off-by-hours bugs.
“Could not parse that date.” means the string is not a form the Date parser accepts, stick to ISO 8601 (2026-01-01, 2026-01-01T09:30:00Z, 2026-01-01T09:30:00+02:00); other human formats work in some browsers and not others, which is exactly why ISO exists. If the number is 3,600 or 7,200 off from what you expected, the input had no timezone suffix and was read as local time: append Z.
Convert when writing API queries (created_after=…), building test fixtures, setting token expirations, or comparing against timestamps in code.
This page is a focused view of theUnix Timestamp Converter & Epoch Converter, which has the full set of options.
Both. Seconds is the common interchange unit for APIs and JWT claims; the milliseconds row (seconds × 1000) is what JavaScript's Date constructor expects.
Almost always timezones: “2026-01-01T09:00” without a suffix is interpreted in your local timezone, not UTC. Append Z for UTC or an explicit offset like +02:00 to remove the ambiguity.
ISO 8601 forms reliably: 2026-01-01, 2026-01-01T09:30:00Z, 2026-01-01T09:30:00+02:00. Other human formats may work in your browser but are not guaranteed across engines.