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 — and multiplying by 1000 gives JavaScript's milliseconds.
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, which has the full set of options.
This tool outputs seconds, the common interchange unit. Multiply by 1000 for JavaScript's Date constructor, which expects milliseconds.
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.