Unix Timestamp Converter

Quick examples

• 0 → 1970-01-01 UTC
• 1710000000 → 2024-03-09 UTC area

Handy for logs, APIs, JWT exp claims, and database timestamps.

Seconds or milliseconds is guessed from the number of digits, at thirteen

You do not tell this tool which unit your timestamp is in. It counts the digits: thirteen or more is treated as milliseconds, twelve or fewer as seconds. Measured:

• 1760000000, ten digits, is read as seconds and gives 9 October 2026.
• 1760000000000, thirteen digits, is read as milliseconds and gives the same moment.
• 999999999999, twelve digits, is read as seconds and gives a date in the year 33658.

That last one is the heuristic failing honestly rather than quietly: a twelve-digit millisecond timestamp, which is any moment before 9 September 2001, is read as seconds and lands tens of thousands of years in the future. The absurd date is the signal. If you are working with historic millisecond timestamps, multiply by 1000 or add a zero so the digit count clears thirteen, or divide and use the seconds instead.

The results panel always shows both the seconds and the milliseconds figure, so once you have a date you can see which unit it decided on and check it against what you pasted.

The epoch is a fixed moment in UTC, and negative timestamps work

A Unix timestamp counts from 1 January 1970 at 00:00:00 UTC, which POSIX calls the Epoch. It is a count from a fixed instant, not a local time, so the same timestamp is the same moment everywhere in the world. Measured:

• 0 gives 1 January 1970, 00:00:00 UTC.
• -86400 gives 31 December 1969, so dates before the epoch work and need no special handling.

Negative support matters more than it sounds: plenty of systems store a birth date or an archive date as a negative timestamp, and plenty of converters reject them or return nonsense.

The 2038 limit is about 32-bit storage, not about this tool

Measured: 2147483647 gives 19 January 2038, and 2147483648, one second later, gives 19 January 2038 as well, correctly, a second further on. This tool has no trouble with either.

That number is the largest value a signed 32-bit integer can hold, and a system storing timestamps that way overflows to a negative number one second later, landing in 1901. The problem belongs to those systems, not to the arithmetic. If a timestamp you are investigating comes back as 1901 somewhere else and 2038 here, overflow in the other system is the likely explanation.

Four date formats are shown, and only two of them are the same everywhere

The results panel gives the same moment four ways, and the difference between them is the thing to understand:

• ISO (UTC) and UTC string are in UTC. They are identical for everyone who loads this page, and they are what you quote in a bug report, a log or a message to a colleague.
• Local string and the large headline date are in your browser’s time zone, taken from your device. They are the right thing to read and the wrong thing to quote, because the person you send them to may be in another zone.

So if a timestamp needs to travel, use the ISO line. The headline figure is there because it answers “when was this, for me”, which is usually the actual question.

Anything that is not a whole number is refused rather than rounded

The input must be digits, with an optional leading minus. Measured:

• abc gives “Invalid timestamp”.
• 1760000000.5, a timestamp with fractional seconds, also gives “Invalid timestamp”.

Refusing the fractional one is a defensible choice and it will catch you out, because several languages and databases hand out timestamps with a decimal point, and some log formats use fractional seconds as standard. Drop the fractional part and paste the whole number, or multiply by 1000 and paste that as milliseconds, which keeps three of the decimal places.

What this tool deliberately does not do

• No time zone choice. It shows UTC and your own local zone, and nothing in between. For converting a moment between two named zones use Time Zone Converter.
• No fractional seconds, as above, and no microsecond or nanosecond timestamps, which are 16 and 19 digits and will be read as milliseconds and give absurd dates.
• No leap seconds. Unix time ignores them by definition, so a timestamp cannot represent 23:59:60.
• No other epochs. Windows FILETIME, Apple’s 2001 epoch and Excel serial dates all start somewhere else and will not convert here.
• No parsing of written dates. It converts a number to a date and a date picker to a number; it will not read “last Tuesday”.
• No live clock. Nothing ticks, and nothing is saved.

Nothing is uploaded. The conversion uses built-in browser date functions running on your device, and the timestamp never leaves it.

Sources

• The definition of the Epoch and of seconds since the Epoch: POSIX, base definitions, general concepts. pubs.opengroup.org
• How the browser turns a millisecond count into a date, and the range it supports: Date. developer.mozilla.org
• The ISO line shown in the results, and why it is the one to quote: RFC 3339, a profile of ISO 8601. rfc-editor.org/rfc/rfc3339
• The time zone rules used for the local figures: the IANA time zone database. iana.org/time-zones

Every behaviour and every converted value on this page was measured against this tool as it is published, in a browser, on 14 October 2026. Where the page says what the tool does not do, that is a statement about this tool, not about Unix time in general.