Unix Timestamp Converter

How to use Unix Timestamp Converter

What it does & when you need it

You've got a number like 1719936000 in a log line, a database row, or a JSON payload, and you need to know what moment in time it actually represents — or you have a date and need the epoch value a system expects. This converter goes both ways: paste a Unix timestamp to see it as an ISO 8601 string, a UTC string, your local time, and a relative "how long ago", or paste a date to get the seconds and milliseconds back. It runs entirely in your browser using the same Date engine your code uses, so nothing you paste is transmitted anywhere.

How to use

1. Pick a direction with the toggle: Epoch → Date turns a number into readable times, Date → Epoch does the reverse. Press Sample on the input buffer to load a realistic value for whichever direction is active.
2. Type or paste into the input buffer. In epoch mode the status bar tells you whether the value was read as seconds or milliseconds; in date mode it confirms the string parsed. The output buffer updates as you type, and an unparseable value shows an inline error instead of a result.
3. Press Now (or Ctrl/Cmd + Enter) to drop in the current time for the active direction. Use Copy on the output to grab the conversion, or Clear to reset the input.

Things worth knowing

Seconds or milliseconds — count the digits. Unix time is the number of seconds elapsed since 1970-01-01T00:00:00Z, the epoch. A ten-digit value is seconds; a thirteen-digit value is almost always milliseconds, because that is what JavaScript's Date.now() returns. This tool auto-detects using a simple rule — anything whose absolute value reaches 1e12 is treated as milliseconds — so 1719936000 and 1719936000000 resolve to the same instant. If your value comes out a thousand times off, you fed seconds where a system wanted ms (or the reverse). If you then need to inspect where such a value came from, a JWT decoder is handy: the exp and iat claims are Unix seconds, not milliseconds, and mixing them up is a classic bug.

The epoch is always UTC. A timestamp is an absolute point on the timeline with no timezone attached — the zone is applied only when you render it. That is why the same number shows one wall-clock time in this tool's "Local time" line and a different one in the UTC line, and why a colleague in another region sees yet another. Store and transmit UTC (or the raw epoch) and convert to local only for display.

The year-2038 problem is real but narrow. Systems that store Unix time in a signed 32-bit integer can only count to 2147483647 seconds, which overflows on 2038-01-19T03:14:07Z and wraps to a negative number — December 1901. Anything using 64-bit integers or JavaScript's floating-point number (which this tool uses) is unaffected for any date you will ever care about. Negative timestamps are valid too: they simply represent moments before 1970.

Unix time ignores leap seconds. Roughly every value maps to a real second, but the count deliberately skips the ~27 leap seconds inserted since 1972 to keep UTC aligned with Earth's rotation. That makes Unix time not a perfectly uniform count of SI seconds — fine for app logic, timestamps, and diffs, but wrong for precise interval astronomy. When you need scheduled recurrence rather than a single instant, reach for a cron expression generator, and when your timestamp is buried in a larger structure, the JSON formatter will pretty-print it first.