Timestamp Converter

What a Unix timestamp is

A Unix timestamp is a count of seconds since midnight UTC on 1 January 1970, a moment known as the epoch. It's how most software stores a point in time, because a single number needs no time zone, no calendar and no ambiguity about whether 03/04 means March or April. The cost is that nobody can read one. That's what this page is for.

Paste a number and you get the date. Paste a date and you get the number. Everything is worked out in your browser as you type, so nothing you paste — a log line, a database dump, a customer's record — is sent anywhere.

Seconds or milliseconds?

This is the mistake the tool exists to catch. 1754661600 and1754661600000 are the same instant, but the second is in milliseconds, and reading one as the other lands you in 1970 or in the year 57000. Different systems disagree: Unix, Postgres and most APIs count seconds; JavaScript, Java and Go's UnixMilli count milliseconds.

The unit is worked out from how many digits you paste — up to 11 is seconds, 12 to 14 is milliseconds, then microseconds and nanoseconds above that. That rule holds for every timestamp between 2001 and 2286, which is every one you're likely to meet. Whatever it picks is shown underneath the box, and you can force the reading with the Read a number asbuttons if you're working with something unusual.

How to use it

1. Paste a timestamp, or type a date like 2026-08-08 14:30.
2. Pick the time zone you want the answer in — it starts on yours.
3. Copy whichever format you need.

A date typed without a zone is read in the zone you've selected, not your own, so choosing Tokyo and typing 14:30 means half past two in the afternoon in Tokyo. A date that carries its own offset — anything ending in Z or +09:00 — is already unambiguous and the selection doesn't change it.

Time zones and summer time

Offsets are not fixed properties of a place. New York is five hours behind UTC in January and four in July, and the changeover dates differ from Europe's. This tool asks the browser's copy of the IANA time zone database for the offset at the instant in question rather than applying today's offset to a date last winter, which is the usual way these conversions go wrong.

Two consequences are worth knowing. When clocks go forward, an hour never happens: 01:30 on the morning of the change doesn't exist in the UK, and a reading inside that gap is resolved forward to 02:30, the same as every date library does. When clocks go back, an hour happens twice, and a reading inside it is taken as the first of the two.

What it won't do

• Leap seconds. Unix time pretends they don't exist — it assumes every day is exactly 86,400 seconds long. So does this converter, and so does nearly everything else you'll compare it against.
• Sub-millisecond precision. Microsecond and nanosecond values are read correctly, but JavaScript's clock stops at milliseconds, so the extra digits come back as zeros rather than invented precision.
• Dates beyond ±100 million days from 1970, roughly the years 275760 and −271821. Past that, a timestamp can't be represented and the tool says so rather than showing nonsense.

Frequently asked questions

What's the timestamp right now?

It's ticking at the bottom of the page in seconds, alongside the ISO form. PressingUse now drops it into the box so you can convert from it.

Why does my timestamp come out an hour off?

Almost always summer time. Check the UTC offset shown in the details — if you're comparing against a system that applied today's offset to a date from the other side of a clock change, that system is the one that's wrong.

Can I link someone to a particular timestamp?

Yes. The address bar updates as you type, so copying the URL and sending it shows that same instant when it's opened.

What happened before 1970?

Timestamps go negative. -14182940 is the Apollo 11 landing. Negative values are handled here, though plenty of other software refuses them.