Epoch Bin: Unix Timestamp Converter

A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — the Unix epoch. Computers store dates this way because a single integer is trivial to compare, sort and do arithmetic on, unlike a formatted string such as "August 18, 2026." Nearly every programming language, database and API exposes time as this kind of epoch value somewhere under the hood, in either seconds (the Unix standard) or milliseconds (JavaScript's Date.now() and many web APIs) — and the two are easy to confuse, since a 13-digit millisecond value and a 10-digit second value both look like plausible input at a glance. Epoch Bin exists to make that value legible: paste a timestamp below and see it rendered in seven formats at once — ISO 8601, RFC 2822, UTC and local date strings, relative time, and both Unix units — or go the other direction and turn any date back into its epoch equivalent, entirely in your browser, for the moment you're debugging a log line, a database row or a JWT claim and just need the right date, right now.

Most of the time that means one value at a time — but not always. When a log export or a CSV hands you a whole epoch column, you can convert a whole column at once rather than pasting rows one by one, and when all you actually want is the current Unix timestamp, ticking live, that has a page of its own.

Until you hand it a value, the converter below is a live clock: it counts the current epoch second by second, in UTC or in your own zone, and holds still the moment you paste an instant of your own. Each of the seven formats has a copy button beside it, the instants you convert stay in a history panel you can reopen, and the share link the toolbar copies carries the instant, the clock face and the zone in its query string — so the page someone else opens is the reading you were looking at rather than an empty box.

Seconds, milliseconds, and telling them apart

A Unix timestamp is a count, not a format, so nothing in the number itself declares which unit it is in. In practice the digit count does the declaring: for any date in the last thirty years, ten digits is seconds, thirteen is milliseconds, sixteen is microseconds and nineteen is nanoseconds. The converter above detects the unit and shows you both readings, but if all you want is to settle the question for a value sitting in front of you — is that number seconds or milliseconds? — that check has a page of its own.

The same count is also the thing that runs out. A signed 32-bit clock stops at 2147483647, which is 03:14:07 UTC on 19 January 2038, and wraps to 1901 one second later rather than failing.

Because it is a count, arithmetic on it is arithmetic: how long until that ceiling, or a week after some other instant, is one subtraction or one addition of 86,400 seconds a day. The two places that goes wrong are months, which are not a fixed number of seconds at all, and boundaries — "the start of today" is a question about a timezone, not about the number. Adding, subtracting and diffing timestamps has a page that keeps those three apart.

Reading a timestamp in your own language

Every language spells this conversion differently, and each spelling has its own trap. Python's datetime.fromtimestamp() hands back a naive local datetime unless you pass a timezone, so the Python reference leads on naive versus aware. JavaScript's Date works in milliseconds where nearly everything else works in seconds, which is the single most common cause of a date that is off by a factor of a thousand — the JavaScript reference has both directions as one-liners. In SQL the call is FROM_UNIXTIME(), to_timestamp() or datetime(…, 'unixepoch') depending on the engine, and the SQL reference lists each one. A spreadsheet is the odd one out: Excel counts days since 1899-12-30 rather than seconds since 1970, so going to an Excel serial date is arithmetic, not a cast.

If what you have is a string rather than a number, the ISO 8601 and RFC 3339 converter goes both ways too. And if the real question is what the instant reads as somewhere else, choose a zone — the timestamp has none of its own, which is exactly why the same value can be Tuesday evening in one office and Wednesday morning in another.

When the timestamp is buried in something else

Plenty of values carry a time inside them without looking like one. A JWT's exp, iat and nbf claims are epoch seconds — paste a token into the expiry decoder and it will tell you whether it is already dead. A MongoDB ObjectId's leading four bytes are epoch seconds, so the ObjectId itself carries the creation date even without a createdAt field. A Discord snowflake packs milliseconds since Discord's own epoch into its high bits, which is what the snowflake and tag decoder unpacks. The full index groups all of them by what you are trying to do.

Frequently asked questions

What is a Unix timestamp?

A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 — the Unix epoch. Also called epoch time or POSIX time, it lets a date be stored as a single integer instead of a formatted string.

Is a Unix timestamp in seconds or milliseconds?

It depends on the system. The Unix standard is seconds (ten digits for a current date), but JavaScript's Date.now() and many web APIs use milliseconds (thirteen digits). If you're not sure which unit you have, count the digits — this converter and the dedicated milliseconds-or-seconds tool both auto-detect it.

Why does the Unix epoch start at January 1, 1970?

1970 was chosen as a round, recent reference point by early Unix developers, not for any technical reason. Once operating systems, file formats and databases adopted it, it became the de facto standard that virtually every modern system still uses. It is also why anything that coerces to zero — a null, an empty string, a missing field — renders as a date stuck at January 1, 1970 rather than as an error.

What happens to Unix timestamps in 2038?

Systems that store a Unix timestamp as a signed 32-bit integer will overflow at 03:14:07 UTC on January 19, 2038, wrapping to a negative number and rendering an invalid or 1901 date — the "Year 2038 problem." Most modern 64-bit systems already store timestamps as 64-bit integers and are unaffected.

Does a Unix timestamp include a time zone?

No. A Unix timestamp is always relative to UTC and carries no time zone information at all. Time zone only enters the picture when the number is formatted into a human-readable date string, which is why this converter shows both a UTC and a local date string side by side.

How do I convert a Unix timestamp to a readable date?

Paste the number into the field above. Epoch Bin displays it in seven formats at once, with no server round trip or install, entirely in your browser.

How do I check if a JWT is expired?

A JWT's exp claim is a Unix timestamp in seconds marking when the token stops being valid. Paste the token into the dedicated JWT expiry decoder to see its iat, exp and nbf claims decoded to readable dates instantly.

Does a MongoDB ObjectId contain a Unix timestamp?

The first four bytes of every MongoDB ObjectId are a Unix timestamp in seconds. The ObjectId to timestamp converter extracts it with no database round trip, and can generate a boundary ObjectId from a date for range queries.