RunLocalTools

Timestamp Converter

Convert a Unix timestamp into a human-readable date, or a date into its Unix timestamp — in seconds or milliseconds, in your local timezone or UTC — computed instantly in your browser.

The specific confusion this tool exists to fix

Unix timestamps are simple in concept (seconds since January 1, 1970 UTC) but trip people up constantly in practice, for a few very specific reasons: some systems use seconds while others use milliseconds, and mixing them up produces a date that’s either in 1970 or thousands of years in the future depending on which direction you got wrong. Timezone handling adds another layer — a timestamp itself has no timezone (it’s an absolute point in time), but the moment you render it as a date, you have to pick one, and “midnight” in your local time and “midnight” in UTC are different exact moments unless you happen to be in the UTC timezone yourself.

How to use it

  1. Paste a Unix timestamp to convert it to a readable date, or enter a date to get its Unix timestamp — the tool works in both directions from the same interface.
  2. A unit selector clarifies whether you’re working in seconds or milliseconds, and the tool will also try to auto-detect this from the number of digits (a 10-digit number is almost certainly seconds; 13 digits is almost certainly milliseconds).
  3. See the converted result in both your local timezone and UTC simultaneously, side by side, rather than needing to toggle back and forth.
  4. A live “current timestamp” display updates in real time, useful as a quick reference or for grabbing “right now” as a starting point.
  5. Use the relative time output (“3 days ago,” “in 2 hours”) alongside the absolute date, which is often what you actually need when debugging why something scheduled for the “wrong” time.
  6. Copy any individual value — the raw timestamp, the ISO 8601 string, or the formatted local/UTC date — directly from its field.

Common situations this solves

  • Debugging why an event or record shows the wrong time in an app or database, usually traced back to a seconds-vs-milliseconds mismatch or a timezone assumption that didn’t hold.
  • Converting a timestamp from an API response or log file into a date you can actually read at a glance.
  • Scheduling something programmatically and needing the exact Unix timestamp for a specific future date and time.
  • Comparing two timestamps from different systems to check whether they actually represent the same moment, once timezone and unit differences are accounted for.
  • Setting up a JWT’s expiration claim or a cache-control header, both of which are commonly expressed in Unix time and easy to get wrong by an order of magnitude if you paste in the wrong unit.

Frequently asked questions

Why does my timestamp show a date in 1970 or a bizarre far-future date? This is almost always a seconds-vs-milliseconds mismatch — pasting a millisecond timestamp into a system expecting seconds makes it look like it’s from 1970 (because the number, interpreted as seconds, is actually only a few days past the epoch), while pasting a seconds timestamp where milliseconds are expected pushes the date thousands of years into the future.

Does a Unix timestamp have a timezone built into it? No — a Unix timestamp represents an absolute, timezone-independent moment (seconds since the epoch in UTC). Timezone only enters the picture when you convert that moment into a human-readable calendar date and clock time, which is why this tool always shows both local and UTC renderings side by side rather than picking one for you.

What’s the difference between the Unix timestamp and the ISO 8601 format also shown here? A Unix timestamp is a single number with no inherent formatting. ISO 8601 (like 2026-09-01T14:30:00Z) is a standardized, human-readable string format that also encodes the date, time, and timezone explicitly, and is what most modern APIs use in JSON payloads instead of a raw number, precisely because it’s less ambiguous.

How far into the future or past can this tool convert? Standard 32-bit Unix timestamps have a known limit (the “Year 2038 problem”), but this tool uses JavaScript’s native Date handling, which comfortably supports dates spanning roughly 273,000 years in either direction from the epoch — far beyond any practical use case.

Can I convert a date that’s already in a specific timezone, not just my local one? Yes — the timezone selector lets you specify an arbitrary source timezone when entering a date, so you can accurately convert “3pm in Tokyo” into its correct Unix timestamp rather than assuming it means 3pm in your own local timezone.