Epoch Converter: Unix Timestamp to Date and Back

What is a Unix timestamp converter?

A Unix timestamp is a count of seconds since 1970-01-01T00:00:00Z, the Unix epoch. Zero is that instant exactly; positive numbers count forward and negative numbers count backward, which is how the Apollo 11 landing gets a timestamp at all: -14,182,940 seconds, because it happened before 1970 and the counter still runs in reverse. An epoch converter turns that raw number into a date you can read, and turns a date you pick back into the raw number a system expects.

This one runs entirely in your browser. Switch between Timestamp to date and Date to timestamp, and every field updates as you type, with no request sent anywhere. It auto-detects whether a pasted number is seconds or milliseconds, lets you override that guess, and always shows the UTC and local readings side by side so the two never get silently conflated.

How to use it

1. Pick a mode. Choose Timestamp to date to decode a number, or Date to timestamp to encode a date. A Use current time button in either mode fills in the present instant for you.
2. Enter the value. In Timestamp to date, type or paste the number and use the Unit pills if you need to force Seconds or Milliseconds instead of Auto-detect. In Date to timestamp, use the date-and-time picker and set Read as to Your local time or UTC, depending on which one the number is meant to represent.
3. Read and copy the results. Timestamp to date shows UTC, your local time labelled with your browser's own timezone, ISO 8601, and a relative reading like 3 hours ago. Date to timestamp shows seconds, milliseconds and ISO 8601. Click any result to copy it.

A timestamp has no timezone

A Unix timestamp names one instant in the universe, nothing more. It is never right to say a timestamp is in UTC, because it isn't in any zone at all; the timezone only shows up later, when that instant gets formatted for a human to read. The value 1750000000000 is 15 June 2025 at 15:06 in UTC and 11:06 the same day in New York, but in Tokyo it is 00:06 on 16 June, a different calendar date entirely, from the exact same number.

The date-and-time picker in Date to timestamp has the mirror-image problem. Typing 2026-07-27 12:00 does not name an instant by itself; read as UTC versus read as local time on a machine set to Madrid produces two timestamps two hours apart, for the same digits on the screen.

That is the entire reason the Read as switch exists in Date to timestamp, and why Timestamp to date prints both UTC and your local time rather than picking one. Neither field is guessing on your behalf; you tell the tool which clock the digits belong to.

The two bugs that catch everyone: units and overflow

The most common timestamp bug is reading seconds as milliseconds, or the reverse. 1750000000 and 1750000000000 mark the identical instant, 2025-06-15T15:06:40Z, one in seconds and one in milliseconds. Feed the milliseconds value into code expecting seconds and you land in the year 57425; make the opposite mistake and a real, recent moment collapses to 21 January 1970. This tool's auto-detect exists to catch that: it flips its guess at 100 billion, which as seconds is the year 5138 and as milliseconds is March 1973, so it correctly reads any real-world timestamp either way, but it is still a heuristic, and the page names it as one rather than pretending certainty.

The second is the 2038 problem, which is a hardware limit, not a rounding error. A signed 32-bit seconds counter tops out at 2,147,483,647, which is 2 to the 31st power minus 1, and that value is 2038-01-19T03:14:07Z. One second later, such a clock wraps around to 1901-12-13T20:45:52Z. The tool flags any value that crosses that ceiling so the overflow is visible rather than silent.

A subtler point: Unix time ignores leap seconds. A leap second was inserted at the end of 2016, yet Unix time still counts exactly 86,400 seconds across that day, because every Unix day is defined as exactly 86,400 seconds by fiat. That is why Unix time and UTC drift apart by a handful of seconds over the decades, even though people casually call a timestamp UTC. Two more honest limits worth knowing: your local-time line depends on your browser reporting its timezone correctly, and if that's wrong, only that line is wrong, since UTC and ISO 8601 don't touch your settings; and historical dates rely on your browser's timezone database, so an old date in a zone with an unusual historical offset can render differently across browsers.

Why is it free?

Every tool on FreeToGenerate.com runs client-side, right in your browser tab. This converter never uploads a timestamp or a date anywhere, never asks for an account, and never saves anything after you close the page. There's no watermark, no usage cap and no paid tier hiding a feature you actually need, because there was never a server bill to recover in the first place.