← Back

Timestamp Converter

Convert between Unix timestamps and dates

10/13/2026, 18:20:28 · 2026-10-13T10:20:28.000Z
1791886828 (sec) · 1791886828000 (ms)

About Timestamp Converter

This tool converts between Unix timestamps (the number of seconds or milliseconds since 00:00:00 UTC on 1 January 1970) and human-readable dates. The page has two halves: in the upper one you enter a timestamp and see the matching local time and UTC time; in the lower one you pick a date and time and see the matching timestamp in seconds and milliseconds. It does only those two conversions. It has no custom output formats, no choice of other time zones, and no date arithmetic or time-difference calculator. The 'local time' it shows depends on the time zone currently set on your device.

How to use it

  1. Type a number into 'Unix timestamp (seconds or milliseconds)'. When the page opens it is already filled with the current time in seconds. The 'Now' button next to it refreshes it to the current moment.
  2. The result box right below updates immediately, in the form 'local time · ISO format', for example '2023/11/15 06:13:20 · 2023-11-14T22:13:20.000Z'. The Z at the end of the ISO part means UTC.
  3. To go the other way, pick a date and time in the 'Date & time' field, which is the browser's own datetime-local control.
  4. The box under it shows two values, 'seconds (sec) · milliseconds (ms)', and you can copy whichever you need. If the input cannot be parsed, you will see 'Invalid timestamp' or 'Invalid date'.

A worked example

Enter 1700000000 (10 digits). The tool treats it as seconds and gives the UTC time 2023-11-14T22:13:20.000Z; on a device set to China Standard Time (UTC+8) the local part reads 2023/11/15 06:13:20. Enter 1700000000000 (13 digits) and it is read as milliseconds, giving exactly the same moment. In the other direction, selecting 2024-01-01 00:00:00 on a UTC+8 device gives 1704038400 (sec) and 1704038400000 (ms). Selecting the same wall-clock value on a device set to UTC gives 1704067200 (sec), which is 8 hours (28800 seconds) later. So the same date typed on devices in different time zones produces different timestamps, which is expected because the date field is interpreted in the device's local zone. These numbers were obtained by running the same Date logic, not estimated.

Supported features and known limits

  • Seconds versus milliseconds is decided by the number of digits in the integer part: more than 10 digits is treated as milliseconds, otherwise as seconds (surrounding spaces and a minus sign are not counted). So up to 10 digits means seconds (good until roughly the year 2286), and 11 or more digits means milliseconds. An 11-digit value such as 99999999999 is read as milliseconds and lands in 1973 instead of the far future.
  • Surrounding spaces are ignored and the minus sign is not counted, so 1700000000 with a trailing space and a negative 10-digit seconds value such as -1700000000 are both correctly read as seconds.
  • The input must be purely numeric (an optional minus sign and decimal point are allowed). A fractional seconds value like 1700000000.123 keeps its millisecond part, and text such as 123abc shows 'Invalid timestamp'.
  • Only two results are available: your device's local time zone and UTC. You cannot pick Tokyo, New York or any other zone.
  • The precision of the date picker depends on your browser's control; it usually goes to the minute and some browsers allow seconds. The seconds value in the result is rounded down to a whole second.
  • When the page first opens, the 'Date & time' box is pre-filled with the current time in your device's local time zone.
  • Leap seconds are not handled; JavaScript timestamps do not include them.

Is my timestamp 10 digits or 13?

Classic Unix timestamps (C, Python's time.time(), database UNIX_TIMESTAMP functions) are in seconds and currently have 10 digits. JavaScript's Date.now() and Java's System.currentTimeMillis() are in milliseconds and currently have 13. The tool picks one by length, so there is nothing to switch. If you have a 16-digit microsecond or 19-digit nanosecond value, divide by 1,000 or 1,000,000 first, otherwise the result will be a date thousands of years away.

Why does my result differ by several hours from another site?

Almost always it is the time zone. A timestamp identifies one exact moment regardless of zone; only the 'local time' part is shown in your device's zone. To cross-check, look at the ISO part ending in Z. That is UTC, independent of your device, and should match the UTC result of any other tool.

Can I convert dates before 1970?

Going from a date to a timestamp, yes - the result is simply negative. In the timestamp-to-date direction, keep the length check above in mind, because the minus sign counts as a character. A small negative value like -86400 is under the limit and is read as seconds, but a negative 10-digit seconds value will be read as milliseconds and needs converting by hand.

What does 'Invalid timestamp' mean?

The input is not purely numeric (it contains letters or other symbols), or the value is outside the range JavaScript dates can represent (about 100 million days either side of 1970, roughly the years 271821 BC to AD 275760). Clear the field or click 'Now' to recover.

Privacy and processing

All conversion happens in your browser using JavaScript's built-in Date object. The code does not send any timestamp or date you enter to a server, and it keeps no history. The 'Now' button reads your own device clock, so if that clock is wrong, the results will be wrong too.