Unix time is a single integer that represents a moment in time as a count of seconds. It is the most widely used date format in server logs, databases, APIs, and authentication tokens.
What Unix time is
Unix time counts the seconds that have elapsed since 1970-01-01 00:00:00 UTC. That reference point is called the Unix epoch. Every second that passes, the Unix timestamp increments by one — no time zones, no daylight saving, no leap second ambiguity in practice.
The format is timezone-agnostic by design. Convert to a local date only at the display layer. Store and compare timestamps as plain integers, and you avoid an entire class of timezone-related bugs.
Where epoch 0 comes from
The date 1970-01-01 was chosen by early Unix developers at Bell Labs as a convenient round number, close to when the system was being built. There was no technical requirement for that specific date — it was a pragmatic choice that became a universal standard.
Other systems chose different epochs: Windows FILETIME counts 100-nanosecond intervals since 1601-01-01; Apple's Core Data uses 2001-01-01. When working with data from multiple platforms, check which epoch applies before comparing values.
Seconds vs milliseconds
A 10-digit timestamp like 1756000000 is in seconds. A 13-digit timestamp like 1756000000000 is in milliseconds. JavaScript's Date.now() returns milliseconds — divide by 1000 before comparing against a seconds-based value from a server or JWT claim.
The digit count is the fastest way to tell them apart. If the number is around 1.7 trillion (13 digits), it is milliseconds. Around 1.7 billion (10 digits), it is seconds. Some systems also use microseconds (16 digits) or nanoseconds (19 digits).
Divide-by-1000 errors produce dates 1000 years in the future or show a timestamp in the early 1970s — both are common debugging symptoms when the unit is wrong.
How to convert a Unix timestamp
Open the Unix timestamp converter and paste your value into the input. The tool detects whether the input is seconds or milliseconds based on digit count, then displays the UTC date and your local timezone date side by side.
To go the other direction, enter a human-readable date and the tool returns the corresponding Unix timestamp in both seconds and milliseconds. Use the timezone converter if you need the same moment expressed in multiple zones before converting to a timestamp.
Common timestamp values you'll encounter
The current timestamp (mid-2026) sits around 1,756,000,000. The year 2000 was 946,684,800. The year 2038 problem is the Unix timestamp 2,147,483,647 — the maximum value a 32-bit signed integer can hold — which maps to January 19, 2038 at 03:14:07 UTC. Systems that store timestamps as 32-bit integers will overflow at that moment.
Most modern systems use 64-bit integers, which extend the range to the year 292,277,026,596. The year 2038 problem is mostly a concern for embedded systems, legacy databases, and old PHP code using 32-bit builds.
JWT iat and exp claims are always Unix timestamps in seconds, never milliseconds. Check the cron expression builder when you need to schedule recurring tasks aligned to specific Unix time boundaries.
Reading timestamps in practice
The most common workflow is decoding a JWT or parsing a server log: copy the raw integer, paste it into the Unix timestamp converter, and immediately see whether the token has expired or when the log entry was written.
For ongoing work with scheduled events or cron jobs, pair timestamp conversion with the cron expression builder to confirm that your schedule aligns with the intended UTC times. Timestamps in logs are always UTC — convert to local time only when communicating the time to a human reader.