Is my timestamp in seconds or milliseconds?

With Auto-detect , this tool guesses from the number of digits: 10 digits or fewer (roughly 2001–2286) is treated as seconds, and 13 digits as milliseconds, the two most common conventions (Unix time() vs. JavaScript's Date.now() ). If you know which one you have, pick it explicitly in the Unit menu instead of relying on the guess.

Why do I get a different timestamp for the same date depending on the Interpret as option?

Because 2025-01-15T10:30:00 genuinely is a different instant in UTC than it is in, say, India Standard Time. There is no time zone written in the string, so something has to decide. This is also a real JavaScript quirk worth knowing on its own: the language's own Date parser treats a bare date like 2025-01-15 as UTC but a bare date- time like 2025-01-15T10:30:00 as local time: same missing time zone, opposite silent default. This tool asks you instead of guessing inconsistently.

Does it handle dates before 1970?

Yes. Unix time is just negative before the epoch, and this tool accepts negative timestamps and dates as far back as JavaScript's Date can represent (about 273,790 years in either direction).

Why does the highlighted date end in +05:30 instead of Z?

Both describe the same instant. Going from a timestamp, the highlighted answer is ISO 8601 written in your own time zone with its offset from UTC (in India, 2025-01-15T16:00:00.000+05:30 ), so it reads as your local time and still means exactly one moment wherever it is pasted. If the system you are pasting into wants UTC, copy the ISO 8601 (UTC) row instead: 2025-01-15T10:30:00.000Z .

What time zone is the Local value shown in?

Whatever your browser and operating system are set to: the grid names it (for example "Local (Asia/Kolkata)"), so it is never ambiguous. Since this runs entirely on your device, the same timestamp will show a different local line on a colleague's screen in another time zone; that is expected, not a bug.

Unix Timestamp Converter

How to use

Choose a direction: Timestamp → Date or Date → Timestamp.
Going from a timestamp, pick the unit: Auto-detect works for anything from the last ~55 years. Going from a date, pick Interpret as (UTC or your browser's local time) for dates with no time zone written in them.
Paste the value, or press Convert now on the live clock at the top to fill in the current moment. The clock's own Copy buttons take the current Unix time in seconds or milliseconds directly.
Read the result: the answer in large type (your local date and time, or the Unix time going the other way) with how long ago or from now it is, then every representation in one list: your local time, ISO 8601 in your time zone and in UTC, the UTC date, and Unix seconds and milliseconds. The answer to the direction you chose comes first and is highlighted.
Press Copy on any row, or the main Copy button (or Ctrl+Enter in the input) for the highlighted answer.

One number, several honest defaults

A Unix timestamp is a count of seconds (or milliseconds) since 1 January 1970 UTC, unambiguous as a number, but useless to a human until it is turned back into a date. Going the other way has a hidden trap: a date and time with no time zone attached is not one fixed instant, it is a different instant depending which zone you assume. Most converters pick one silently; this one asks, and shows you both the number and every common representation of the date side by side so nothing is hidden behind a single answer. Unix timestamps show up constantly in raw form: an API response, a database column, a JWT's exp claim (readable directly on the JWT Decoder); this is the tool for converting one on its own.

Example

The Unix timestamp 1736937000 (seconds) becomes:

2025-01-15T10:30:00.000Z
Wed, 15 Jan 2025 10:30:00 GMT

In your browser the headline shows that moment in your own time zone, and the highlighted answer is ISO 8601 with your UTC offset: for India Standard Time, 2025-01-15T16:00:00.000+05:30, the same instant as the Z form above.

Going the other way, 2025-01-15T10:30:00 with Interpret as: UTC becomes the Unix timestamp 1736937000, the same instant, both directions.

Options explained

Direction: Timestamp → Date / Date → Timestamp switches which side you type into and which side is computed.
Unit (Timestamp → Date only): Auto-detect / Seconds / Milliseconds reads the number of digits: 1736937000 (10 digits) auto-detects as seconds and resolves to 2025-01-15T10:30:00.000Z; 1736937000000 (13 digits) auto-detects as milliseconds and resolves to the same instant, 2025-01-15T10:30:00.000Z.
Interpret as (Date → Timestamp only): UTC / Local time only matters when the date you paste has no time zone of its own. 2025-01-15T10:30:00 becomes Unix time 1736937000 under UTC, but 1736917200 under Local time in a browser set to India Standard Time (UTC+05:30). Add an explicit Z or +05:30 to the date and this option is ignored; the offset you wrote always wins.
Convert now fills the input with right now, in whichever direction is active (the clock above it ticks once a second, and pauses while the tab is in the background). On the date side it is written in your local time with your UTC offset (in India it looks like 2025-01-15T16:00:00+05:30), so the result is right whichever Interpret as option is selected. Load sample inserts the worked example above; Clear empties the box.

Edge cases and common errors

Not a plain number. 1736937000s stops with "A Unix timestamp is a plain integer (optionally signed), with no letters, colons, commas or units". No letters, units or thousands separators are accepted; strip them before pasting.
Astronomically large input is rejected, not silently wrapped. A 30-digit number of digits stops with "That does not resolve to a valid date"; a merely huge-but-finite one (say, treated as milliseconds when it should have been seconds) stops with "That does not resolve to a valid date" rather than returning a nonsense date far outside any calendar humans use.
Unparseable dates. Free text that matches no recognised shape, like not a date, stops with "Could not parse that as a date. Try ISO 8601, e.g. 2025-01-15 or 2025-01-15T10:30:00". ISO forms (2025-01-15, 2025-01-15T10:30:00, with or without an offset) are always understood; anything else falls back to the browser's own date parser, which accepts many formats but (like the no-offset case above) reads them in local time.
Out-of-range calendar fields roll over rather than error. 2025-13-40 (month 13, day 40) is not rejected: it becomes 2026-02-09T00:00:00.000Z, the same way native Date arithmetic works. Useful when a value is computed (e.g. "30 days from now") and genuinely inconvenient when it hides a typo. Double-check the month and day if the result looks like the wrong year.
Pre-1970 dates are negative, not an error. See the FAQ.
Fractional seconds in a date (2025-01-15T10:30:00.5) are read as part of a second (500 ms), matching ISO 8601 rather than being misread as minutes or a separate field.

Do the same thing in code

The exact conversions this page performs, in a few languages:

// JavaScript
new Date(1736937000 * 1000).toISOString();        // timestamp -> date
Math.floor(Date.parse('2025-01-15T10:30:00Z') / 1000); // date -> timestamp (UTC, explicit offset)

# Python
import datetime
datetime.datetime.fromtimestamp(1736937000, datetime.timezone.utc)
datetime.datetime.fromtimestamp(1736937000).astimezone().isoformat()  # your local time, with offset
int(datetime.datetime(2025, 1, 15, 10, 30, tzinfo=datetime.timezone.utc).timestamp())

Both languages have the same no-offset ambiguity this tool routes around: JavaScript's Date.parse and Python's naive datetime objects assume different defaults depending on the exact string shape and platform. Pass an explicit UTC offset (as above) whenever the zone actually matters.

Runs entirely in your browser: this page is a static file with no server behind it, so nothing you paste can be uploaded. Last reviewed 11 October 2026 by Parthesh Gupta. Implements ECMA-262: the Date object.