CrispUtils

Unix timestamp converter

Paste an epoch timestamp to see it as a date in your own timezone and in UTC, or pick a date to get the timestamp. Handles seconds, milliseconds, microseconds and nanoseconds.

Now:

Your timezone:

Your file is processed by your own browser. Nothing is uploaded, stored or logged.

A Unix timestamp counts the seconds since midnight UTC on 1 January 1970. It is the format almost every log file, database and API uses internally, because it is a single number with no timezone attached and no ambiguity about formatting.

The everyday difficulty is that it is unreadable, and that different systems use different scales: Unix tools use seconds, JavaScript uses milliseconds, and some databases use microseconds or nanoseconds. Get the scale wrong by a factor of a thousand and your date lands in 1970 or fifty thousand years from now. This converts in both directions at every scale, and shows the result in your timezone, UTC and ISO 8601 at once.

How to use this tool

  1. Paste the timestamp. Set the unit to match its scale — a 10-digit number is seconds, 13 digits is milliseconds.
  2. Read the results: ISO 8601, UTC, your local time, a readable format and a relative description.
  3. To go the other way, pick a date and time in the date field and the timestamp appears.
  4. Press Now for the current timestamp in the selected unit; a live counter also ticks below the input.
  5. Copy either the timestamp or the ISO string.

Worked example

Reading a log line

A log records 1758000000. Pasting it with the unit set to seconds shows 16 September 2025, 05:20 UTC, and the relative line tells you how long ago that was without any mental arithmetic.

A date stuck in 1970

Records are displaying as 20 January 1970. The stored value was milliseconds but the code read it as seconds — dividing by a thousand. Switching the unit here confirms the diagnosis in a couple of seconds.

Common use cases

  • Reading timestamps out of application logs
  • Checking JWT iat and exp claims
  • Working with database columns stored as epoch integers
  • Setting a cut-off time in an API query
  • Converting between timezones during an incident
  • Diagnosing dates that are wrong by a factor of a thousand

Common mistakes

  • Mixing seconds and milliseconds — The most common timestamp bug there is. Ten digits is seconds, thirteen is milliseconds — check the length before anything else.
  • Assuming a timestamp carries a timezone — It never does. An epoch value is always UTC; the timezone is applied only when it is formatted for display.
  • Storing local time instead of epoch — Local times break at daylight saving transitions, when one hour repeats and another does not exist. Store epoch or a timezone-aware type.
  • Ignoring the 2038 problem — A signed 32-bit timestamp overflows on 19 January 2038. Anything still using a 32-bit integer for time needs to move to 64-bit.

Frequently asked questions

Is a Unix timestamp in UTC?

Always. It is a count of seconds from a fixed instant, with no timezone component. Timezones are applied only when converting it to a human-readable date, which is exactly why timestamps are the safe thing to store.

How do I tell seconds from milliseconds?

Count the digits. Ten digits is seconds for any date between 2001 and 2286. Thirteen is milliseconds. Sixteen is microseconds and nineteen is nanoseconds.

What is ISO 8601 and why use it?

A standard text format, like 2026-09-15T14:30:00Z. It sorts correctly as plain text, is unambiguous about timezone, and is parsed identically everywhere — unlike regional formats where 03/04 could be March or April.

Does it handle dates before 1970?

Yes. Timestamps before the epoch are negative; enter the negative number or pick the date directly.

Why does my local time differ from UTC by an odd amount?

Not every offset is a whole hour. India is UTC+5:30, Nepal is UTC+5:45, and several regions shift by half an hour for daylight saving. Your browser's timezone is shown under the date field.

What happens in 2038?

Systems storing time as a signed 32-bit integer overflow on 19 January 2038 and wrap to 1901. Modern systems use 64-bit values, which are good for far longer than anything else will last.

Last updated 2026-09-26