Developer Free · no signup

Timestamp Converter

Convert between Unix timestamps and human-readable dates. Supports seconds, milliseconds, ISO 8601.

Paste a Unix timestamp (seconds or milliseconds since 1970-01-01 00:00:00 UTC) and this tool converts it to a human-readable date in both UTC and your local timezone — or go the other way and turn a calendar date into an epoch value. It auto-detects whether your number is in seconds (10 digits) or milliseconds (13 digits), so you don't have to remember which format your API returned. Everything runs in your browser, so timestamps never leave your machine.

Updated Krawly Editorial TeamIn-house engineers, writers & reviewers

Explore More Free Tools

Discover 150+ free tools for web scraping, SEO analysis, OSINT, and more. 30 free uses every day — no signup required.

150+ Free Tools No Signup Required JSON / CSV / Excel 30 Uses / Day
Quick answer

Paste a Unix timestamp (seconds or milliseconds since 1970-01-01 00:00:00 UTC) and this tool converts it to a human-readable date in both UTC and your local timezone — or go the other way and turn a calendar date into an epoch value. It auto-detects whether your number is in seconds (10 digits) or milliseconds (13 digits), so you don't have to remember which format your API returned. Everything runs in your browser, so timestamps never leave your machine.

What is Timestamp Converter?

A timestamp converter translates between Unix epoch time — the number of seconds (or milliseconds) elapsed since the Unix epoch, 00:00:00 UTC on 1 January 1970 — and normal human-readable dates. Because epoch time is a single integer independent of timezones, it's the format most databases, log files, JWT tokens, and REST APIs use to store instants. This tool decodes those integers into readable dates and encodes dates back into epoch values.

How to use Timestamp Converter

  1. 1

    Paste your timestamp

    Drop in a Unix timestamp like 1704067200 or a millisecond value like 1704067200000. The tool detects the magnitude automatically — 10 digits is treated as seconds, 13 digits as milliseconds.

  2. 2

    Read the decoded date

    You immediately see the equivalent date rendered in UTC and in your browser's local timezone, plus the day of the week and the ISO 8601 string.

  3. 3

    Or reverse the conversion

    Switch to date-to-timestamp mode, pick a calendar date and time, and the tool returns the corresponding epoch value in both seconds and milliseconds.

  4. 4

    Copy the result

    Copy the value you need — the epoch integer for a database query, or the ISO string for a log entry — with one click.

Try it when you need to…

  • Try it when an API gives you "1704067200" and you need to know what date that actually is
  • Try it when your log timestamps look like "1704067200000" and you're unsure if they're seconds or milliseconds
  • Try it when you need to hardcode an exact expiry epoch value into a test or config

Use cases

  • Debugging an API response that returns created_at as a raw epoch integer instead of a date
  • Reading Unix timestamps inside server log files while triaging an incident
  • Decoding the iat and exp claims in a JWT to check whether a token has expired
  • Setting a precise expires-at value when writing a database record or cache TTL
  • Confirming that a millisecond timestamp from JavaScript's Date.now() matches a seconds-based backend value

Key features

Auto-detects seconds vs milliseconds from the number's length
Shows the result in both UTC and your local timezone side by side
Bidirectional — epoch to date and date to epoch in one tool
Outputs ISO 8601, RFC-style, and relative ("3 hours ago") formats
Runs entirely client-side, so timestamps are never uploaded

Tips & best practices

The single most common bug is a 1000x error: Unix time in most databases is seconds, but JavaScript's Date and Date.now() use milliseconds. If your date lands in 1970 or in the year 55000, you've mixed the two — divide or multiply by 1000.

Epoch time is always UTC by definition. The timezone offset you see is applied only when rendering; the underlying integer carries no timezone, which is exactly why it's safe to store.

Watch for the 32-bit signed limit: on 19 January 2038 (timestamp 2147483647) systems that store epoch as a 32-bit int overflow. This 'Year 2038 problem' is why modern systems use 64-bit timestamps.

Negative timestamps are valid and represent dates before 1970 — e.g. -86400 is 31 December 1969.

Frequently asked questions

A seconds-based Unix timestamp counts whole seconds since 1970 and is typically 10 digits (e.g. 1704067200). A millisecond timestamp counts thousandths of a second and is typically 13 digits (e.g. 1704067200000) — this is what JavaScript's Date.now() returns. Confusing the two produces dates that are off by a factor of 1000, landing you either in 1970 or thousands of years in the future.

Yes. By definition the Unix epoch is anchored to 00:00:00 UTC on 1 January 1970, and the counter is timezone-independent. Any timezone you see is applied only at display time when the integer is formatted into a readable date; the stored number itself never changes with location or daylight saving.

Systems that store Unix time in a signed 32-bit integer can only count up to 2,147,483,647 seconds, which is reached at 03:14:07 UTC on 19 January 2038. One second later the value overflows into a negative number, wrapping back to 1901. Modern languages and 64-bit systems avoid this by using 64-bit timestamps, which won't overflow for roughly 292 billion years.

JWT iat (issued-at) and exp (expiry) claims are standard Unix timestamps in seconds (NumericDate per RFC 7519). Paste the integer here to see the human-readable date. If exp is earlier than the current timestamp, the token has expired.

Yes. Negative values represent instants before the epoch — for example -1 is 23:59:59 UTC on 31 December 1969, and -86400 is exactly one day before the epoch. Some older libraries reject negatives, so validate if you're working with historical dates.

Most often it's a timezone issue: the tool shows UTC alongside your local time, and if you compare the UTC value to your local clock you'll see the offset. Daylight saving transitions can also shift local rendering by an hour even though the epoch value is unchanged.

No. The conversion is pure arithmetic done in your browser with JavaScript's Date object, so the timestamp you paste never leaves your device. That makes it safe to decode timestamps from private logs or internal tokens.