Unix Timestamp Converter

Convert Unix epoch seconds or milliseconds into local and UTC dates, or generate the current timestamp instantly.

Runs in your browser Convert
Convert epoch seconds or milliseconds using your browser clock and timezone.

 
  
 
 
 
How to use Timestamp Converter
 
     
  1. Paste a Unix timestamp into the input box.
  2. Choose Auto, Seconds, or Milliseconds.
  3. Review local time, UTC time, and ISO output.
  4. Use Current time when you need a fresh timestamp.
    5.  
 
 
 
Why this tool exists
 
Unix timestamps are compact, timezone-neutral numbers used in APIs, databases, logs, JWT claims, queues, and analytics events. They are efficient for systems but awkward for people. This converter turns epoch seconds or milliseconds into readable local and UTC dates so you can debug time-based behavior without guessing.
The most common mistake is mixing seconds and milliseconds. JavaScript dates use milliseconds, while many APIs and JWT claims use seconds. A value like 1710000000 is likely seconds; a value like 1710000000000 is likely milliseconds. CleanWebTools detects the likely unit and also lets you choose explicitly when you need control.
Timezone handling matters. A timestamp represents one instant, but the displayed clock time changes depending on local timezone. This page shows both local time and UTC to reduce ambiguity. For distributed systems, logs, and security investigations, UTC is usually the safer reference.
This tool runs entirely in the browser and does not need a server. It pairs naturally with the JWT Decoder when checking exp, iat, and nbf claims, and with JSON Formatter when inspecting API payloads that include epoch values.
 
 
 
Common examples
 
     
  • Seconds vs milliseconds, the off-by-1000 bug: new Date(1710000000) renders 1970-01-20 (treated as 1.7 billion ms), while the same value as seconds is new Date(1710000000 * 1000) = 2024-03-09 16:00:00 UTC. Same digits, fix is the *1000.
  • Decode a JWT exp claim: a payload exp of 1735689599 (10 digits, so seconds) converts to 2024-12-31 23:59:59 UTC — confirm a token expiry instead of eyeballing the integer.
  • Watch the overflow live: feed 2147483647 to see 2038-01-19 03:14:07 UTC (the signed 32-bit ceiling), then 2147483648 to see the wrap to 1901-12-13 20:45:52 UTC — the exact failure embedded systems hit at the Epochalypse.
    •  
 
 
 
FAQ
 
 
 
Is my value in seconds or milliseconds, and how do I tell?
 
Count the digits. For any present-day date a ~10-digit number is seconds (e.g. 1710000000), a ~13-digit number is milliseconds (1710000000000), ~16 is microseconds, and ~19 is nanoseconds. The factor between seconds and ms is exactly 1000, so the classic bug is feeding a 10-digit seconds value into JavaScript's new Date(t) — which expects ms — and landing in January 1970; the fix is new Date(t * 1000). The digit heuristic only holds for roughly 2001–2286, so it lies for dates near the epoch or far future.
 
 
Why does the same timestamp show a different calendar day in two timezones?
 
Because a Unix timestamp has no timezone at all — it is just a count of seconds since 1970-01-01 00:00:00 UTC, naming one global instant. The 'date' only exists once you render it in a chosen zone, so the instant 1700000000 is 2023-11-14 in Los Angeles (UTC-8) but already 2023-11-15 in Tokyo (UTC+9). Bugs appear when code formats an instant in the server's local zone and the server later moves region or hits DST; store and compare in UTC and only localize at the display edge.
 
 
What is the 2038 problem and which database columns are at risk?
 
A signed 32-bit integer caps at 2,147,483,647 seconds = 2038-01-19 03:14:07 UTC; one second past that it overflows to negative and wraps back to 1901-12-13 20:45:52 UTC. So any epoch stored in an INT column (rather than BIGINT) is a silent time bomb, and MySQL's TIMESTAMP type historically inherits this same 2038 ceiling while DATETIME does not. An unsigned 32-bit value only buys you until 2106-02-07 06:28:15 UTC — BIGINT is the real fix.
 
 
 
 

By Alpha Loop · Last updated