Date Format Converter

One instant, six spellings

The field starts with 1700000000, a round Unix timestamp that is worth knowing by sight. Here is what each row shows for it, with the browser set to New York time:

Paste 1700000000000 (13 digits) or Tue, 14 Nov 2023 22:13:20 GMT and you get the same six rows, because all three are the same moment. Paste 2026-10-16T09:30:00+02:00 and the ISO row reads 2026-10-16T07:30:00.000Z: the offset is applied and the result is restated in UTC.

What it accepts

• All digits, up to 10 long: Unix seconds. Leading and trailing spaces are trimmed.
• All digits, 11 or more: Unix milliseconds, the form JavaScript's Date.now() and many logging systems produce.
• Eight digits that form a real date: 20261016 is read as October 16, 2026 at 00:00 UTC. An eight-digit number that is not a valid date, like 12345678, stays a Unix timestamp (May 23, 1970).
• Anything else: passed to the browser's built-in date parser. ISO 8601 and RFC 2822 work in all current browsers. Other text is up to the browser.

It does not read natural language ("next Friday"), day-first dates, fractional timestamps like 1700000000.5, or negative timestamps. It does not let you choose a target time zone either: Local always means the zone your device is set to. For zone-to-zone conversion, use the time zone converter. For a whole column of timestamps, the epoch batch converter does them all at once.

Notes on each output

ISO 8601 here is the strict profile most APIs want: UTC, a T separator, milliseconds, and Z. It is also valid RFC 3339. The differences between the two standards, and the one string that is valid in one but ambiguous in the other, are covered in ISO 8601 vs RFC 3339.

Unix (seconds) is rounded down, so 1700000000999 ms becomes 1700000000 s. That is the usual convention, and it means the seconds value never points to a moment after the original.

Local uses US English formatting (month first, 12-hour clock) with a short zone name, whatever your system language is. It is for reading, not for storing: a string like EST is not a reliable machine-readable offset.

Relative picks the largest unit that fits (years, months, weeks, days, hours, minutes, seconds) and rounds. A month counts as 30 days and a year as 365, so it is an approximation. It is worked out when you type, not on a live clock, so it can lag if you leave the page open.

The conversion runs entirely in your browser with the built-in Date and Intl APIs. Nothing you paste is sent anywhere.

Frequently asked questions

How does it tell Unix seconds from milliseconds?

By digit count. A number of up to 10 digits is read as seconds and anything longer as milliseconds, which is right for any seconds value from 1970 to the year 2286 and any milliseconds value from late April 1970 on. A milliseconds value from the first four months of 1970 has 10 or fewer digits and would be misread as seconds. One exception: an 8-digit number that is a real calendar date in YYYYMMDD form, such as 20261016, is read as that date at midnight UTC rather than as seconds.

Why does a plain date like 2026-10-16 show the previous evening under Local?

JavaScript reads a date-only ISO string as midnight UTC, not midnight in your zone. In New York that instant is 8:00 PM on October 15. Add a time without an offset, for example 2026-10-16T00:00, and it is read as local midnight instead. Add Z or an offset like +02:00 and it is read exactly as written.

Is the RFC 2822 row really RFC 2822?

It is the output of JavaScript's toUTCString(), for example Tue, 14 Nov 2023 22:13:20 GMT. RFC 2822 and its successor RFC 5322 list GMT as an obsolete zone name that parsers must still accept, so mail software reads it fine, and it is also the exact format HTTP uses for headers such as Last-Modified and Expires. It is always in GMT, never with a local offset like -0500.

Why does the ISO 8601 output always end in Z?

The ISO row comes from toISOString(), which always gives UTC with millisecond precision and a Z suffix. The tool does not produce an ISO string with your local offset. If you need one, the Local row shows the same moment in your zone.

Can it read 16/10/2026 or other day-first dates?

No. Anything that is not all digits is handed to the browser's own date parser, which does not accept day-first slashed dates and treats 10/16/2026 as month-first. ISO 8601 strings and the RFC 2822 / HTTP style are the reliable inputs. Other free-text forms like Oct 16 2026 work in current browsers, but the JavaScript spec does not require it.

Can I convert a negative timestamp for a date before 1970?

Not reliably. The number check only accepts plain digits, so a value like -86400 is passed to the browser's date parser instead, which may misread it as a year or reject it. Use an ISO date such as 1969-12-31 for dates before the epoch.