Epoch Converter (Unix Timestamp)

This timestamp converter turns a Unix epoch number into a date, and a date back into that number, live in both directions — and the fastest way to get either wrong is to misread which unit the number is in. Type or paste into either field below and both directions update as you go: no convert button, no separate UTC or local mode to pick. The current moment ticks at the top of the page the whole time, so there's always a known-good number on screen to compare a pasted one against.

Unix timestamp to date converter, both directions

Either field is live. Paste a number into the timestamp field and the date, UTC time, local time and Discord markup all update from it; type a date instead and the timestamp field rewrites itself to match. Whichever field you last touched is the one being read — the other one is derived and redrawn, so there's nothing to swap and nothing to submit. The answer panel always shows three things about the same instant at once: the UTC clock time, your local clock time, and the raw number in both seconds and milliseconds — so switching which one you're reading from costs one glance, not a re-conversion.

Seconds vs milliseconds: the 1000x error trap

This is the actual reason a dedicated converter is worth having. Date.now() in JavaScript returns milliseconds. C's time(), most Unix command-line tools and a large share of REST APIs return seconds. Feed a millisecond value into something expecting seconds, or the reverse, and the result is off by a factor of exactly 1,000 — not garbage, not an error, just a date more than thirty thousand years away or a date in early 1970, both of which look obviously wrong once you see them but neither of which the number itself warns you about.

Paste a number here and the reading sentence beneath the field states, in words, which unit it decided on and why: ten digits reads confidently as seconds, thirteen digits reads confidently as milliseconds, and anything outside those two bands is flagged as ambiguous rather than guessed at silently. The alternate reading is always shown too, one tap away behind a button, so you can check what the number would mean in the other unit before committing to either.

Reading timestamps from logs, APIs and database columns

An unexplained integer in a log line or a JSON payload is the most common reason to reach for this page. A few patterns worth knowing before you paste: JSON Web Token claims (exp, iat, nbf) are defined as seconds by the JWT spec, so a token that looks expired when read as milliseconds probably isn't. Many payment and platform APIs — the kind that return a created or updated field as a bare integer — use seconds as well. A column in a database that stores epoch time as a bigint could be either, depending on which language wrote it: a Node.js backend that calls Date.now() before an insert is writing milliseconds, while a script built around time.time() in Python or a Unix shell command is writing seconds. When a paste comes out of a system you don't control, the digit count and the reading sentence above are the fastest way to settle it rather than assuming.

The current epoch timestamp, live

The number at the top of the page is the current epoch timestamp in seconds, updating once a second for as long as the tab is open (or fixed at the moment the page loaded if your browser is set to reduce motion, with a manual refresh available instead). Press "Use now" to drop that exact moment straight into the timestamp field — useful for confirming what "right now" looks like in a log format you're trying to match, or for building a just-in-the-future Discord timestamp without doing the arithmetic yourself.

UTC and local time side by side

Every conversion shows UTC and your chosen local zone at the same time, rather than making you pick one. The zone defaults to the one your device reports, and switching it in the selector is remembered on this browser for next time. Typing a date without an explicit offset reads it in whichever zone is currently selected; typing one with its own Z or +02:00 suffix uses that offset instead and the answer panel says so, so a string with its own zone information is never silently reinterpreted in the wrong one.

Discord timestamp markup: the seven style codes

Discord accepts a timestamp written as <t:seconds:style> and renders it in whichever timezone and date format the reader's Discord client is set to, not the sender's — which is the entire reason to use the markup instead of typing a time yourself. Convert your moment here and every one of the seven style codes appears with a live preview and its own copy button: short time, long time, short date, long date, short date-and-time, long date-and-time, and relative. Relative — <t:…:R> — is the one worth knowing by name: it renders as "in 3 hours" or "2 days ago" and keeps recalculating itself every time someone reads the message, which a plain typed time never does. Discord only takes whole seconds, so anything finer than a second in the number you converted is dropped from the markup even though it's kept in the exact figures above it.

Microseconds and nanoseconds: when the number is too big

Some databases and tracing tools store time at finer resolution than milliseconds — a 16-digit number is very likely microseconds, and a 19-digit number is very likely nanoseconds. Both are too large to be a sensible date in either seconds or milliseconds, so instead of converting to a nonsense date thirty-thousand-odd years out, the tool names the likely unit directly and shows the value divided down to a plausible number of seconds, as a starting point for converting it properly at the resolution it was actually recorded in.

Negative timestamps, the 2038 problem and other edge cases

A negative number is a date before 1 January 1970 and converts normally here, with a note confirming that's what it is — but it's worth knowing that some databases and older log parsers reject negative epoch values outright, so a negative number that works fine here can still be refused somewhere else. Going the other direction in scale: systems that store time as a signed 32-bit integer run out of room at 03:14:07 UTC on 19 January 2038, the well-known "Y2038" limit, and wrap around to a date in 1901 instead of continuing forward — this converter isn't affected by that limit, but it's worth checking any older system, embedded device or 32-bit build against that exact number if you're not sure it's clear of it. And if a date you type lands exactly on a clock change — a local time that a daylight-saving transition skips or repeats — a note under the result says which occurrence was used, rather than leaving it ambiguous.