Epoch UNIX Timestamp Converter. Free Online Tool: Ferra

How do you convert a UNIX timestamp to a date?

1700000000 means nothing to a human and everything to a server. A UNIX timestamp counts seconds since January 1, 1970 at 00:00:00 UTC, the instant programmers call the epoch, and converting one means adding that many seconds to the epoch and formatting the result as a date. Paste a timestamp here and you see the moment twice, once in UTC and once in your local zone, with seconds and milliseconds told apart automatically.

The number itself carries no time zone. It names a single instant; a zone only appears when you format it, which is why one timestamp can land on two different calendar dates depending on where it's read. Units are the other trap. Second-based systems produce 10-digit values today while millisecond-based systems produce 13-digit ones, and the tool tells them apart by length. Negative timestamps are valid too. They fall before 1970.

When timestamps arrive by the thousand, a log export, an API response, paste them into Ferra and convert the whole column at once, raw values kept alongside the readable dates.

How the epoch converter works

The conversion runs as you type. Digit count decides the unit, around ten digits reads as seconds, thirteen as milliseconds, and the same instant then prints twice: a date and time in UTC, and again in your browser's local time zone.

Timestamp: Digits only: no quotes, no commas. Ten-digit values are treated as seconds and thirteen-digit values as milliseconds; negatives work fine and land before 1970.

What the output means

Enter 1700000000. You get Tuesday, November 14, 2023 at 22:13:20 UTC. The local line depends on where you sit, in New York the same instant reads 17:13:20 on November 14, five hours behind UTC. Add three zeros and enter 1700000000000, the same value in milliseconds, and the result is identical, because the unit comes from the digit count.

Feed milliseconds to a converter that assumes seconds and you get a date tens of thousands of years in the future: easy to laugh at on a page, easy to miss inside a script. The reverse error, seconds read as milliseconds, lands in January 1970, which is why brand-new records sometimes appear to predate the internet.

When to use the epoch converter

Server logs store time as raw timestamps, and API responses and database exports do the same. When you're tracing a bug or reconstructing an incident timeline, converting the key timestamps to readable dates in one shared zone, usually UTC, is the first step to seeing what happened in what order.

Then there's everything with an expiry. Auth tokens and signed URLs carry expiry timestamps; so do cache entries and scheduled jobs. Paste one and you know immediately if the thing has expired, and by how much. The check runs in reverse too: when you hand a computed timestamp to an API, convert it back first and confirm it means the date you intended.

Tips for the epoch converter

Almost every timestamp bug comes down to a unit or a zone; these five catch both.

Count the digits: Ten digits is seconds, thirteen is milliseconds. Sixteen means microseconds: divide by 1,000,000 before converting.
Compare in UTC: When timestamps come from different systems, convert everything to UTC before ordering events. Local zones hide off-by-hours bugs.
Watch the date boundary: The local date can differ from the UTC date for the same instant, so "what day did this happen" has two honest answers: say which zone you mean.
Sanity-check the year: A result in 1970 or absurdly far in the future almost always means a unit mix-up, not exotic data.
Keep the raw value: Convert for reading, but store and share the original timestamp. It's unambiguous in a way formatted dates never are.