Unix Timestamp Converter

Convert in either direction

Two tabs share one instant. “Timestamp → Date” is selected when the page loads. “Date → Timestamp” is the other direction. Switching tabs keeps the same millisecond. There is no separate Convert button. The result updates as you type, and again when you change the unit or the time zone.

1. On Timestamp → Date, paste a number or a date into the field. The placeholder is 1700000000 or 2026-09-25 14:22. Auto, s and ms sit beside that field and apply only to a numeric value.
2. On Date → Timestamp, use the picker labeled “Pick a date and time in the selected time zone”, or the text field labeled “Or paste a date”. The picker is set to a 0.001 second step, so a browser that honors that step can hold milliseconds. Typing in one of those two fields clears the other.
3. Choose a time zone. The menu starts on your browser’s zone, marked with “ · Local”. Click a result row to copy that format.

On load, Timestamp → Date is filled from the device clock, the same action as “Use now”. After that the field stays put. “Current Unix time” is a separate line: whole seconds, redrawn every second, and it does not rewrite the field. Press Use now when you want the field to match the clock again. On Date → Timestamp, Use now keeps the current millisecond. On Timestamp → Date, Auto and s write whole seconds and drop that millisecond; ms writes the full Date.now() count.

An empty field says “Enter a Unix timestamp or a date.” A value the page cannot read says “Enter a Unix timestamp, or a date like 2026-09-25 14:22.” The previous numbers stay on screen, the rows are disabled, and the hint ends with “Previous result is inactive.” Fix the field and the same rows become clickable again.

The three Try buttons jump back to Timestamp → Date, set the unit to Auto, and fill one sample: 1700000000 (Unix seconds), 2026-09-30T13:23:34.238916463Z (the button is labeled ISO + offset; the sample itself uses Z and extra fractional digits), or 2026-09-03T130315.857 (Compact log time).

Seconds or milliseconds

Auto counts digits in the integer part after it removes a leading @, spaces, commas, underscores and leading zeros. Eleven digits or fewer are seconds. Twelve or more are milliseconds. You can force s or ms, then return to Auto. The choice re-reads the same digits. It does not multiply or divide what you typed.

1700000000 has 10 digits, so Auto reads seconds. The hint is “Read as seconds · 10 digits · displaying in UTC” when UTC is selected. The instant is Tuesday, 14 November 2023, 22:13:20 UTC, and the ISO 8601 · UTC row is 2023-11-14T22:13:20.000Z. The same ten digits forced to ms are 1,700,000 seconds after the epoch: 1970-01-20T16:13:20.000Z. The Seconds row then shows 1700000. That is the usual “why is this 1970?” mistake.

The other way is just as sharp. 1700000000000 has 13 digits, so Auto reads milliseconds and lands on that same November 2023 instant. Forcing s treats every digit as seconds and produces +055840-11-08T22:13:20.000Z, year 55840. The page still shows a result. A far-future year is the signal to switch the unit, not a sign that the number was accepted as milliseconds.

The 11-digit and 12-digit boundary is the rule, not “about ten digits.” 99999999999 has 11 digits and is seconds: 5138-11-16T09:46:39.000Z. 100000000000 has 12 digits and is milliseconds: 1973-03-03T09:46:40.000Z. Today’s Unix seconds are 10 digits. They stay seconds under Auto until the integer part grows to 12 digits, which is year 5138. Padding with zeros does not change the count: 0000000000001700000000 is still 10 significant digits and still 14 November 2023.

While Auto is selected on a numeric value, the page also tries the other unit. If that reading fits the supported range, a line appears such as “As milliseconds: 1970-01-20T16:13:20.000Z” with a button “Use milliseconds” (or “As seconds” and “Use seconds”). The button only checks the matching unit. A reading that falls outside the range is omitted, so a value already at the edge of the calendar may show no alternate line.

Seconds · s

Unix tools, most databases and many APIs. A fractional second such as 1700000000.5 is kept in the millisecond instant. The Seconds row is still the whole number 1700000000.

Milliseconds · ms

JavaScript, Java and many log pipelines. Thirteen digits is the current shape. The Milliseconds row is the full integer, including a non-zero millisecond.

Numbers the field will clean up

A numeric value may start with @, the way some Unix tools print a timestamp. Spaces, commas and underscores are removed before the digits are counted, so @1700000000, 1,700,000,000 and 1_700_000_000 are the same ten-digit second count. The decimal mark for a number is a dot. A comma is never a decimal mark in a number, because every comma is deleted first. 1,5 becomes 15 and reads as 15 seconds, 1970-01-01T00:00:15.000Z, not as one and a half seconds.

Scientific notation such as 1.7e9 is not a timestamp here. Hexadecimal is not either. Both fall through to the same “enter a Unix timestamp or a date” error. Microsecond and nanosecond integers are rejected by size: more than 16 integer digits, or a millisecond instant outside ±8.64×10¹⁵, produces “Outside the supported date range. Use seconds or milliseconds, not microseconds or nanoseconds.”

Dates, ISO 8601 and compact log times

A date is a 4- to 6-digit year, a month and a day, separated by - or /. The time is optional. With no time, the value is midnight. With a time, put T or a space before H:MM, then an optional :SS. A fraction of one to nine digits may follow a dot or a comma. A zone may follow, with or without a space: Z, UTC, GMT, +08, +0800 or +08:00. Hours in an offset run from 00 to 23 and minutes from 00 to 59. +24:00 stops with “That UTC offset is not valid.”

2026-09-25 14:22, 2026-09-25T14:22:00Z, 2026/09/25 14:22 and 2026-09-25T14:22:00+08 all match that pattern. +08, +0800 and +08:00 are the same offset. A comma fraction is a fraction, not a thousands separator: 2026-09-30T13:23:34,238Z is the same instant as 2026-09-30T13:23:34.238Z. Month 13, 31 April, a non-leap 29 February, hour 24 and second 60 do not roll over. 2026-02-29 and 2026-09-03T24:00:00Z both say “That date does not exist. Check the month, day and time.” 2024-02-29 is valid and is midnight when you omit the time.

One compact log shape is accepted. Exactly six digits after T mean HHmmss. 2026-09-03T130315.857 is 13:03:15.857. A fraction or a zone may follow those six digits. 2026-09-03T1303 is too short for that shape and too unlike HH:MM, so it is rejected. 2026-09-03T256315 has six digits but hour 25, so it fails the real-date check. Paste the time token alone. A sentence such as “error at 2026-09-30T13:23:34Z” is not parsed, and a week date such as 2026-W40-3 is not an ISO form this page reads.

One further form comes from the browser’s date parser, and only when the calendar pattern above does not match: the text must contain a letter and an explicit zone. The checked example is the HTTP date Tue, 14 Nov 2023 22:13:20 GMT, which is 1700000000 again. That path is explicit, so changing the display zone does not move the Unix time. It is not a general English-date parser, and a log line that merely contains a timestamp still fails.

The hint tells you which rule fired. “Input has a UTC offset · displaying in …” means Z, GMT, UTC or a numeric offset fixed the instant. “Read as a local date in … · changing the time zone changes the timestamp” means there was no offset, so the numbers are wall time in the zone you select.

Time zones, and three views of one instant

The menu lists UTC, America/Los_Angeles, America/Chicago, America/New_York, America/Sao_Paulo, Europe/London, Europe/Berlin, Europe/Kyiv, Asia/Kolkata, Asia/Shanghai, Asia/Tokyo and Australia/Sydney, plus your browser’s zone when it is not already there. America/Chicago is labeled “Chicago · US Central”. Europe/Kyiv is labeled “Kyiv”. The older id Europe/Kiev is labeled Kyiv as well; the browser’s time-zone data decides which id it resolves. Other entries show the IANA name with underscores written as spaces, so America/New_York appears as America/New York. Your own zone gets a “ · Local” suffix.

“Other time zone…” opens a field. The hint is “Enter a city’s IANA time zone, then press Enter. Escape cancels.” Enter applies a name the browser recognizes, including a different capitalisation such as america/chicago, which resolves to America/Chicago. Escape closes the field and leaves the current zone. A name the browser rejects, including an abbreviation such as CST or a bare offset such as +08:00, keeps the current zone and says “Use an IANA time zone such as America/Chicago. The current time zone is unchanged.” Suggestions come from UTC, the built-in list, and the browser’s own IANA list when it exposes one.

Names under Etc/GMT are real IANA ids, and the sign is the opposite of a numeric offset. Etc/GMT+5 is five hours west: at the epoch the page shows 31 December 1969, 19:00:00, with the offset UTC-05:00. Prefer a city. GMT typed as a zone name is accepted and displayed as UTC.

For 1700000000 with Asia/Shanghai selected and the browser zone set to America/New_York, the three readable rows are “Tue, Nov 14, 2023, 22:13:20 UTC”, “Tue, Nov 14, 2023, 17:13:20 EST” and “Wed, Nov 15, 2023, 06:13:20 GMT+8”. The offset badge reads UTC+08:00. Same instant, calendar day included: Shanghai is already Wednesday. The Selected zone row is hidden when the menu is UTC or your browser’s own zone, because it would repeat the UTC row or Your local time.

An explicit offset pins the instant. 2026-10-01T12:00:00Z and 2026-10-01T12:00:00+08:00 keep the same Unix time if you move from Asia/Shanghai to America/Chicago. Only the zone ISO and the readable zone row change. A date with no offset is wall time in the selected zone. 2026-10-01 12:00 is 2026-10-01T04:00:00.000Z in Asia/Shanghai and 2026-10-01T17:00:00.000Z in America/Chicago. A date with no clock is midnight in that zone: 2026-09-25 in Asia/Shanghai is 2026-09-24T16:00:00.000Z. Changing the city after you typed a zoneless date changes the timestamp. The hint says so.

The offset follows the date you entered, using the browser’s zone database. America/Chicago is UTC-06:00 at 12:00 UTC on 1 January 2026 and UTC-05:00 at 12:00 UTC on 1 July 2026. Europe/Kyiv is UTC+02:00 in that January and UTC+03:00 in that July. Local noon is a different Unix time in each season: 12:00 in Chicago is 18:00 UTC on 1 January 2026 and 17:00 UTC on 1 July 2026. America/Phoenix stays on UTC-07:00 on 1 October 2026, with no summer shift. Asia/Kolkata is UTC+05:30; the badge shows the minutes, and the zone ISO ends in +05:30. Europe/London in winter has a zero offset, so the badge reads UTC while the zone ISO still ends in +00:00.

Those offsets come from your browser, not from a zone database shipped with DSOOU. An old operating system can disagree with a server that has newer daylight-saving rules, especially for dates far in the past. The page cannot correct that. UTC is the row to compare when two machines disagree.

Daylight saving, skipped days and repeated hours

When clocks jump forward, some local times never happen. The page rejects them. 2026-03-08 02:30 in America/New_York says “That local time does not exist in America/New York. Enter another time or an explicit UTC offset.” It does not slide the time forward by an hour. The same message covers a 30-minute gap, such as 2026-10-04 02:15 in Australia/Lord_Howe, and a skipped calendar day: noon on 2011-12-30 does not exist in Pacific/Apia, because that local day was skipped. Type the zone under Other time zone… if it is not in the menu.

When clocks fall back, a local time can happen twice. The page keeps the earlier one and names both offsets. 2026-11-01 01:30 in America/New_York is the earlier occurrence, offset -04:00, ISO 2026-11-01T05:30:00.000Z. The note reads “This local time occurs twice. Using the earlier occurrence (-04:00); enter -05:00 explicitly for the later one.” Pasting 2026-11-01T01:30:00-05:00 selects the later instant, one hour on, 2026-11-01T06:30:00.000Z, and the note is cleared because the offset is explicit. The clock on the page can show 01:30:00 for both. The ISO 8601 · UTC row is what tells them apart.

The date picker stores wall time with no offset. On the way back from Timestamp → Date, the page fills that picker in the selected zone. If the picker cannot round-trip the same millisecond — a year the control rejects, or the later of two overlapping local times — the picker is cleared and “Or paste a date” receives the UTC ISO string, including Z. That string is explicit, so a later zone change no longer reinterprets it.

Fractions, leap seconds and the range

Results stop at milliseconds. Extra digits are dropped toward the earlier instant, and the note says “Millisecond precision · extra fractional digits were rounded down.” 2026-09-30T13:23:34.238916463Z becomes 2026-09-30T13:23:34.238Z. Trailing zeros do not count as lost precision: 1.234000 seconds and 2026-09-30T13:23:34.238000000Z produce no note. On a seconds value the first three fractional digits are the milliseconds and anything after that is extra. 1.2349 seconds is 1234 ms, not 1235. On a milliseconds value the whole fraction is extra: 1234.9 is 1234 ms.

Negative values move the same way, further from the epoch rather than toward zero. -1.2349 seconds becomes -1235 ms. The headline reads 31 December 1969, 23:59:58.765, the ISO row is 1969-12-31T23:59:58.765Z, and the Seconds row is -2 because that row is Math.floor of the millisecond count divided by 1000. -0.0001 seconds becomes -1 ms, the clock shows 23:59:59.999, and the Seconds row is -1. Copy Milliseconds or an ISO row when the fraction matters. -86400 is the cleaner pre-epoch example: 31 December 1969, 00:00:00 UTC.

1700000000.5 shows the split inside one second. The headline time is 22:13:20.500 and ISO 8601 · UTC is 2023-11-14T22:13:20.500Z. The Seconds row is 1700000000. The HTTP date is Tue, 14 Nov 2023 22:13:20 GMT, with no millisecond, so it matches the whole second on either side of that half-second. The on-screen clock prints a fraction only when the millisecond part is not zero. Both ISO rows always print three fractional digits.

Unix time on this page is the browser’s clock, which does not insert leap seconds. A UTC leap second such as 2016-12-31T23:59:60Z is rejected with “That date does not exist. Check the month, day and time.” Two timestamps one second apart are always 1000 milliseconds here. The page will not show 23:59:60, and it will not add the accumulated leap-second difference between UTC and a clock that counts every SI second. For an exchange with another system, compare Unix milliseconds or ISO with a Z, and expect them to agree only if that system also ignores leap seconds.

The supported instant is the browser date range: 100 million days on either side of 1 January 1970, which is ±8.64×10¹⁵ milliseconds. The last representable UTC instant in that range is +275760-09-13T00:00:00.000Z, from 8640000000000 read as seconds. The same seconds value cannot be displayed in a zone with a positive offset. In Asia/Shanghai the hint is “That instant cannot be displayed in this time zone. Try UTC.” More than 16 integer digits fails earlier, with the microseconds-or-nanoseconds message, even before the calendar limit is considered.

What each row copies

Every successful conversion fills the same rows from one millisecond instant. Click the row. The label changes to “Copied” for 1.4 seconds, then back to “Copy”. A second click on the same row starts that timer again. If the browser blocks the clipboard, the value is selected and the label reads “Select to copy”. Disabled rows, including a stale result, do not copy.

Seconds

Whole seconds, rounded toward the earlier second with Math.floor. A positive fraction inside the current second disappears. A negative fraction can move to the previous whole second, as -1.2349 does.

Milliseconds

The integer millisecond count, sign included. This is the row that still has 1700000000500 when the seconds row has dropped the .5.

ISO 8601 · UTC

toISOString(): a UTC calendar value, three fractional digits, and Z. 2023-11-14T22:13:20.000Z for the sample above. Years that need more than four digits gain a leading +.

ISO 8601 · Zone

The same wall time in the selected zone, three fractional digits, and a numeric offset. UTC is +00:00, not Z. A zero offset in London winter is still +00:00 on this row. Kolkata ends in +05:30. An offset that is not a whole minute includes the seconds.

HTTP date

The browser’s UTC string, English day and month, whole seconds, and GMT. The sample is Tue, 14 Nov 2023 22:13:20 GMT. This is the shape used in headers such as Last-Modified. Milliseconds are not in it.

UTC

A readable UTC line with a 24-hour clock, such as “Tue, Nov 14, 2023, 22:13:20 UTC”.

Your local time

The same instant in the browser’s zone, even when the menu shows a different city. In the New York example that is “Tue, Nov 14, 2023, 17:13:20 EST”.

Selected zone

The menu’s zone, hidden when that zone is UTC or the browser zone. The Shanghai example is “Wed, Nov 15, 2023, 06:13:20 GMT+8”.

The headline above the rows is the selected zone as well: a short weekday, day, month and year, then a 24-hour clock. For the sample in UTC it reads “Tue, 14 Nov 2023” and “22:13:20”. The relative phrase beside the offset uses English relative time and refreshes every second with the live clock. Under one second it says “now”. Larger gaps use a whole unit cut toward zero, so 90 seconds reads as one minute. A year in that phrase is 31,556,952 seconds and a month is 2,629,746 seconds, which are average lengths. The phrase is a distance, not a calendar count of months. “2 days ago” and “in 1 hour” are the kind of wording it produces.

The clock on this device

Current Unix time, Use now, and the relative phrase all read the clock in the browser. The page does not call a time server, and it is not an authority for the current second. If the laptop clock is two minutes fast, Use now is two minutes fast and the relative phrase is shifted with it. A pasted Unix value does not depend on that clock. Only the “ago” line does, because “ago” is the distance from the device’s now.

Switching direction rewrites the field from the millisecond already on screen. In Timestamp → Date, ms mode writes the integer milliseconds. Auto and s write seconds, with a three-digit fraction when the millisecond part is not zero. If that seconds text would no longer round-trip under Auto — a far-future instant whose second count has 12 or more digits — the field is filled with the millisecond integer instead, so Auto stays on the same instant. In Date → Timestamp the picker is filled when it can hold the wall time, and the UTC ISO string is used when it cannot.

The line under the tool says “Converted on your device using its clock and time zone data. Nothing is uploaded.” The numbers and dates you type stay in the page. DSOOU does not receive them as a tool request and does not store them in an account. Reloading the tab clears the field. Copy what you need first. Access logs for the page view, and any optional page analytics, are described in the privacy policy. Those logs are not a copy of the timestamp you pasted.