Skip to content
BeeTools— Fast. Private. Free.

Unix Timestamp Converter

Runs in your browser

Convert Unix timestamps to dates and back, with the seconds-or-milliseconds question answered.

Developer Tools

Seconds, milliseconds or microseconds — the unit is detected for you.

Common reference points.

Enter a timestamp

You will get the local time, UTC, ISO 8601 and how long ago it was.

Seconds or milliseconds? Unix time is defined in seconds, so a current timestamp has ten digits. JavaScript’s Date.now() returns milliseconds, giving thirteen. Mixing the two is the most common date bug there is: read seconds as milliseconds and you land in January 1970; read milliseconds as seconds and you land tens of thousands of years from now.

Your data never leaves your device

This tool runs entirely in your browser. Nothing you enter is uploaded, stored or logged by BeeTools.

How to use the unix timestamp converter

  1. Choose a direction

    Timestamp to date converts a number you have. Date to timestamp goes the other way, interpreting your input in your local timezone.

  2. Paste the timestamp

    Commas, underscores and spaces from a log line are stripped automatically. The unit is inferred from how many digits it has, and stated above the result.

  3. Check the detected unit

    If the result looks wrong, this is almost always why. A ten-digit number is seconds and a thirteen-digit one is milliseconds — if your source used a different unit, adjust the value by a factor of a thousand.

  4. Copy whichever format you need

    Local time, UTC, ISO 8601, seconds and milliseconds each have their own copy button.

Features

  • Units detected and explained

    Seconds, milliseconds and microseconds are told apart by magnitude, and the reasoning is shown.

  • Converts both directions

    Timestamp to date, or pick a date and time and get the timestamp in seconds and milliseconds.

  • Local, UTC and ISO 8601

    Every common representation at once, with your timezone named so there is no ambiguity.

  • Relative time

    "3 months ago" or "in 2 hours" — usually the thing you actually wanted from a log line.

  • Catches the factor-of-1000 mistake

    Results landing in 1970 or the distant future are flagged rather than quietly returned.

  • Runs locally

    Uses your browser’s own date and timezone data, so results match what your code will do.

About this tool

Unix time counts the seconds elapsed since 1 January 1970 UTC. It is the format almost every log line, database column and API response uses for a moment in time, because a single integer avoids every ambiguity that written dates introduce — no timezones, no locale-dependent ordering, no daylight saving.

The catch, and the reason this tool exists, is units. Unix time is defined in seconds, so a current timestamp has ten digits. JavaScript's Date.now() returns milliseconds, giving thirteen. Some databases store microseconds and some Go and Rust code emits nanoseconds. Mixing them up is the single most common date bug there is: read seconds as milliseconds and you land in January 1970; read milliseconds as seconds and you land tens of thousands of years in the future.

Rather than guessing silently, this converter classifies the number by magnitude, tells you which unit it decided on and why, and flags results that fall outside any plausible range so an off-by-a-thousand error announces itself instead of quietly propagating. It converts in both directions, and shows the result as local time with your timezone named, as UTC, as ISO 8601, and as a relative phrase like "3 months ago" — which is usually the thing you actually wanted to know when you pasted a timestamp out of a log.

Everything is computed in your browser using its own date implementation and timezone database, so results match what your code will do on the same machine.

  • Units detected and explained. Seconds, milliseconds and microseconds are told apart by magnitude, and the reasoning is shown.
  • Converts both directions. Timestamp to date, or pick a date and time and get the timestamp in seconds and milliseconds.
  • Local, UTC and ISO 8601. Every common representation at once, with your timezone named so there is no ambiguity.
  • Relative time. "3 months ago" or "in 2 hours" — usually the thing you actually wanted from a log line.
  • Catches the factor-of-1000 mistake. Results landing in 1970 or the distant future are flagged rather than quietly returned.
  • Runs locally. Uses your browser’s own date and timezone data, so results match what your code will do.

Frequently asked questions

What is a Unix timestamp?

The number of seconds since 1 January 1970 at 00:00:00 UTC, a moment called the Unix epoch. Because it is a single integer measured from a fixed point in UTC, it identifies a moment unambiguously — no timezone, no locale, no daylight-saving edge cases. That is why it is the standard way to record time in logs, databases and APIs.

Is my timestamp in seconds or milliseconds?

Count the digits. A current timestamp in seconds has ten; in milliseconds it has thirteen; in microseconds sixteen. This tool applies that rule and tells you which it chose. The distinction matters enormously: a millisecond value read as seconds resolves to roughly the year 56000, and a seconds value read as milliseconds resolves to a few days after the epoch.

Why does my timestamp resolve to 1970?

Something treated a value in seconds as if it were milliseconds — dividing the real moment by a thousand and landing just after the epoch. It is the classic symptom of passing a Unix timestamp straight into JavaScript’s Date constructor, which expects milliseconds. Multiply by 1000 first.

What is the Year 2038 problem?

Systems storing Unix time in a signed 32-bit integer overflow at 03:14:07 UTC on 19 January 2038, wrapping round to 1901. Modern systems use 64-bit values and are unaffected for billions of years, but embedded devices and old file formats can still be vulnerable. That exact moment is available as a shortcut here.

Does the tool account for leap seconds?

No, and neither does Unix time itself. The standard defines a day as exactly 86,400 seconds and simply repeats a value when a leap second is inserted, so Unix time is not a true count of elapsed physical seconds. For everything short of precision astronomy this is the correct and expected behaviour.

Which timezone are the results in?

Both. The local time uses your device’s timezone, which is named beside it so there is no doubt. UTC and ISO 8601 are shown alongside, which is what you want when comparing against a server log. Going the other way, a date and time you enter is interpreted as local, because that is what someone typing a wall-clock time means.

Related tools

Tools that pair well with this one.