Is a Unix timestamp in seconds or milliseconds?

It depends on the system, which is the problem. The convention is seconds, and `date +%s` and Postgres both use seconds, but JavaScript's `Date.now()` is milliseconds. This page infers the unit from the size of the value and shows you which it chose.

How do I tell seconds from milliseconds?

By magnitude, which is what this page does: 10¹¹ seconds is the year 5138, so a larger number cannot be seconds. That rules units out but cannot prove one, so a small value is assumed to be seconds. The status bar always shows the unit it used.

Why does it refuse my date?

Almost certainly because it is ambiguous. `01/02/2026` is 1 February in most of the world and 2 January in the United States, and guessing would give you a timestamp that looks right and is a day out. Write it as `2026-01-02` and it will convert directly.

What timezone does it use?

Your own, for displaying a result. For converting a date to a timestamp it reads the offset written in the value, falls back to UTC if there is none, and says which of those it did above the answer. The checkbox switches a zoneless time to your local timezone.

Can it handle dates before 1970?

Yes. Negative timestamps are dates before the epoch, and `-1` is 1969-12-31T23:59:59Z. File timestamps and old birth dates land there regularly.

Does this send my data anywhere?

No. Conversion happens in your browser tab. Nothing is uploaded, stored or logged.

Unix Timestamp Converter

Convert a Unix timestamp to a readable date, or a date to a Unix timestamp. Detects whether a value is in seconds, milliseconds, microseconds or nanoseconds, and refuses to guess when a date is ambiguous.

timestamp

Example

waiting

Reading the clock…

Runs in this browser tab. Nothing is uploaded. Times are read in your own timezone unless the value says otherwise.

How to use this tool

A Unix timestamp is the number of seconds since 1 January 1970, 00:00:00 UTC. It is a count, not a calendar date: no month, no year, no timezone, no daylight saving. Every tool that displays one is choosing how to render it, and the choices are where the bugs live.

1`decode` reads a number as a date. `encode` turns a date into a number.
2In `decode`, the unit is worked out from the size of the value and shown in the status bar, with the reasoning underneath.
3In `encode`, an ISO 8601 date is safest. If your value has a time but no timezone, the page says which reading it used — and lets you switch it.

Seconds, milliseconds, and the mistake that never looks wrong

This is the single most common problem with Unix timestamps, and it is worth understanding why it survives. The same instant can be written in four units, and they differ by factors of a thousand:

1767225600        seconds       2026-01-01T00:00:00Z
1767225600000      milliseconds  2026-01-01T00:00:00Z
1767225600000000   microseconds  2026-01-01T00:00:00Z
1767225600000000000 nanoseconds  2026-01-01T00:00:00Z

One instant, four ways.

If you read the millisecond value as seconds, you get a date in the year 33658. If you read the seconds value as milliseconds, you get 1970. Neither produces an error message, a rejected value, or anything that looks broken. They produce a date, formatted correctly, that is wrong — and a wrong timestamp is exactly the kind of thing that gets written to a column and discovered much later.

This page works the unit out from the magnitude of the number: 10¹¹ seconds is the year 5138, and 10¹⁴ milliseconds is the same year, so anything at or below those limits is plausible in that unit. It shows you which unit it chose and why, rather than quietly picking one.

Why 1970, and why it is not arbitrary

The epoch is the start of 1970 because that is when Unix was created and when the systems that counted seconds had already been counting for a while. A counter that starts at zero is easier to reason about than one with an arbitrary origin.

Negative timestamps are real and meaningful: they are dates before 1970. `-1` is one second before the epoch, which is 1969-12-31T23:59:59Z. File modification times, and birth times of anything old enough, regularly land there.

A date is not a timestamp until you pick a timezone

The moment `2026-01-01T00:00:00` appears on its own, it does not name an instant. It is a wall-clock reading, and the same reading is a different moment in London, in Madrid, and in Auckland. You need an offset or a zone to turn it into a number.

2026-01-01T00:00:00Z      1767225600   UTC
2026-01-01T01:00:00+01:00  1767225600   Madrid in January
2026-01-01T13:00:00+13:00  1767225600   Auckland in January

The same wall clock, three zones, three instants.

This page reads a zoneless time as UTC and says so above the answer, where it cannot be missed. If you meant your own timezone, the checkbox under the input switches the reading. A date with no time at all is treated as midnight UTC, which is what the ISO 8601 specification says and what every other tool does.

Why this page refuses 01/02/2026

It is not being difficult. `01/02/2026` is 1 February in most of the world and 2 January in the United States, and nothing in those ten characters says which you meant. A converter that guesses produces a timestamp that looks completely ordinary and is a day out.

So it asks instead, by refusing. The unambiguous forms are `2026-01-02` and `01 Feb 2026`; the first is the one to prefer, because ISO 8601 orders the fields largest-unit-first and is the same format the rest of your tooling speaks.

2026-01-02T15:30:00Z     ISO 8601, UTC            best
2026-01-02T15:30:00+02:00 ISO 8601, with offset    fine
2026-01-02                ISO 8601, date only      midnight UTC
01/02/2026                day or month first       refused
Fri, 02 Jan 2026 15:30:00 GMT   RFC 2822          read, but flagged

Unambiguous, and worth preferring.

Where you will meet these

In a JWT, `exp`, `iat` and `nbf` are all `NumericDate`: seconds since the epoch, as a number. That is the single most likely reason you are reading this page, and the most likely reason to get it wrong, because a library that stores them in milliseconds is not unusual.

JavaScript's `Date.now()` is milliseconds. `new Date().getTime()` is milliseconds. `Math.floor(Date.now() / 1000)` is seconds. The standard library gives you milliseconds and the wire format usually wants seconds, which is where the conversion is easiest to forget.

date -d @1767225600                      # 2026-01-01 00:00:00 UTC
date -u -d '2026-01-01T00:00:00Z' +%s        # 1767225600
date +%s                                     # now, in seconds

The same three lines in a shell.

In SQL, remember that `FROM_UNIXTIME` expects seconds and `UNIX_TIMESTAMP` returns seconds, while some drivers and some column types work in milliseconds. Postgres is stricter and clearer: `to_timestamp()` takes seconds, and there is no millisecond overload to get wrong.

SELECT to_timestamp(1767225600);            -- 2026-01-01 00:00:00+00
SELECT to_timestamp(1767225600) AT TIME ZONE 'Europe/Madrid';

Postgres, which will not let you confuse the two.

Frequently asked questions

Is a Unix timestamp in seconds or milliseconds?: It depends on the system, which is the problem. The convention is seconds, and `date +%s` and Postgres both use seconds, but JavaScript's `Date.now()` is milliseconds. This page infers the unit from the size of the value and shows you which it chose.
How do I tell seconds from milliseconds?: By magnitude, which is what this page does: 10¹¹ seconds is the year 5138, so a larger number cannot be seconds. That rules units out but cannot prove one, so a small value is assumed to be seconds. The status bar always shows the unit it used.
Why does it refuse my date?: Almost certainly because it is ambiguous. `01/02/2026` is 1 February in most of the world and 2 January in the United States, and guessing would give you a timestamp that looks right and is a day out. Write it as `2026-01-02` and it will convert directly.
What timezone does it use?: Your own, for displaying a result. For converting a date to a timestamp it reads the offset written in the value, falls back to UTC if there is none, and says which of those it did above the answer. The checkbox switches a zoneless time to your local timezone.
Can it handle dates before 1970?: Yes. Negative timestamps are dates before the epoch, and `-1` is 1969-12-31T23:59:59Z. File timestamps and old birth dates land there regularly.
Does this send my data anywhere?: No. Conversion happens in your browser tab. Nothing is uploaded, stored or logged.