UNIX Timestamp Converter

About this tool

The UNIX Timestamp Converter translates between epoch timestamps (seconds or milliseconds since 1970-01-01 00:00:00 UTC) and human-readable date/time values. UNIX timestamps appear throughout software engineering: application logs, JWT tokens, database records, API responses, and SIEM event data all use them. This tool converts them in both directions so you can read them without mental math.

Real example

Input: 1700000000 (seconds)

Output:
UTC: Sat, 14 Nov 2023 22:13:20 GMT
ISO: 2023-11-14T22:13:20.000Z
Local: depends on your browser's configured timezone

This timestamp falls in November 2023. The tool automatically distinguishes seconds (10-digit values like 1700000000) from milliseconds (13-digit values like 1700000000000) based on magnitude.

A common JWT claim value to recognize: "exp": 1700000000 means the token expired on 2023-11-14. Always check this during token debugging.

Common use cases

• JWT claim inspection: JWT tokens contain exp (expiration), iat (issued at), and nbf (not before) claims as UNIX timestamps. Paste any of these values here to see the actual date and confirm whether a token is expired. Pair with the JWT Decoder for full token inspection.
• Application and SIEM log analysis: Log management systems often store event timestamps as epoch integers. Convert them here to reconstruct an incident timeline in human-readable form.
• API call preparation: Some APIs require timestamps as integers in their request parameters (expiry windows, rate-limiting windows, signed URL expiry). Convert your target datetime here to get the right integer.
• Database timestamp debugging: Columns stored as BIGINT epoch milliseconds (common in Node.js apps and Cassandra) are unreadable in raw queries. Convert individual values here while debugging.

How it works

Epoch to date: the input is parsed as a number. If the value is greater than 10¹² (a threshold that distinguishes 10-digit second timestamps from 13-digit millisecond timestamps), it is treated as milliseconds; otherwise it is multiplied by 1000. A JavaScript Date object is constructed and formatted in UTC, ISO 8601, and local time. Date to epoch: the datetime-local input is parsed as a Date and getTime() is called to retrieve milliseconds, with a seconds value derived by dividing by 1000.

Common mistakes

• Seconds vs milliseconds confusion: Many JavaScript-based systems (Node.js, browsers) use milliseconds by default. Many Unix-native systems (Python's time.time(), shell date +%s, most databases) use seconds. A 13-digit number is milliseconds; a 10-digit number is seconds. Mixing them up produces timestamps 1000× off.
• Timezone interpretation: Epoch timestamps are timezone-agnostic - they represent an absolute moment in time. "Local" output depends on the timezone configured in your browser, not where the event occurred. Always share timestamps in UTC or ISO 8601 format to avoid ambiguity.
• Year 2038 problem awareness: Signed 32-bit UNIX timestamps overflow on 2038-01-19. Legacy embedded systems and older databases using INT(4) for timestamps will be affected. Systems using 64-bit integers are safe through the year 292,277,026,596.

FAQ

What is epoch time
UNIX epoch time counts seconds elapsed since 1970-01-01 00:00:00 UTC, also called the "Unix epoch" or "POSIX time". It is timezone-independent and used universally across operating systems and programming languages.

What is the timestamp for "now"
In JavaScript: Math.floor(Date.now() / 1000). In Python: import time; int(time.time()). In bash: date +%s.

How do I convert a timestamp in a JWT
Decode the JWT first with the JWT Decoder, then paste the exp, iat, or nbf values here to see the human-readable dates.

Why is the local time different from UTC
UTC is the reference timezone with no offset. Local time applies your browser's configured timezone offset. For example, US Pacific (UTC-8) is 8 hours behind UTC.

Why Unix timestamps are everywhere

Unix epoch time — seconds since 1970-01-01 00:00:00 UTC — is the dominant timestamp format in backend systems, APIs, logs, and security tokens because it has two properties that formatted datetime strings lack: it is timezone-independent and it is a simple integer, making it trivially sortable, comparable, and storable.

A formatted string like 2024-01-15 10:30:00 is ambiguous without a timezone. Is that UTC? US Eastern? The server's local time? Bugs from timezone ambiguity in datetime strings are a well-documented class of production incidents. A Unix timestamp has no timezone — it always means the same point in time regardless of where it is read. Converting to a human-readable local time is a display concern handled at the presentation layer.

The integer representation also means arithmetic is trivial. "Did this event happen within the last 24 hours?" is now - timestamp < 86400. "Is this token expired?" is exp < Math.floor(Date.now() / 1000). No date parsing library required. This is why JWT claims (exp, iat, nbf) all use Unix timestamps, and why virtually every log aggregation system stores timestamps as epoch values.

Millisecond vs second timestamps

The original Unix timestamp is in seconds. JavaScript's Date.now() returns milliseconds. Many modern APIs and databases (MongoDB, Kafka, many cloud services) use millisecond timestamps. A 10-digit number is a second-precision timestamp; a 13-digit number is a millisecond-precision timestamp. This is the most common source of confusion when converting — a millisecond timestamp pasted into a seconds converter produces a date in the year 2001 or earlier (because 1,700,000,000,000 milliseconds = 1,700,000,000 seconds = September 2023, but the raw number treated as seconds = year ~55748).

If a timestamp converts to a nonsensical date (year 1970, or a date far in the future), check whether you need to divide by 1000 first. This tool accepts both formats — enter your value and check the output date for plausibility.

Timestamps in security contexts

JWT expiry: The exp claim in a JWT is a Unix timestamp. When a 401 response says a token is expired, paste the exp value here to confirm when it expired and compare against iat (issued at) to see the token's intended lifetime. Clock skew between servers — even a few seconds — can cause tokens to appear expired prematurely. The nbf (not before) claim is also a Unix timestamp: tokens with a future nbf will be rejected before that time. Use the JWT Decoder to extract these values, then this tool to interpret them.

Log correlation: When correlating events across different systems during an incident, timestamp precision matters. Two events logged as 1700000000 happened in the same second; two events logged as 1700000000123 and 1700000000456 happened 333ms apart. Converting both to human-readable format quickly confirms or rules out causation. The Log Explorer can help filter and sort log lines containing timestamps before you convert individual values here.

Certificate validity: TLS certificate notBefore and notAfter fields are ASN.1 GeneralizedTime strings, not Unix timestamps — but many tools and APIs convert them to epoch for comparison. If you are checking certificate expiry programmatically, the comparison is always against the current Unix timestamp.