What Is Unix Time?
Unix time, also called epoch time, counts the seconds elapsed since 1 January 1970 at 00:00:00 UTC. It is time-zone independent and compact, which is why APIs, databases, logs and operating systems use it. A Unix timestamp is a number, not a formatted date, so it must be converted to a human-readable date for display.
This converter supports Unix seconds, Unix milliseconds, ISO 8601 date strings and local time. It shows UTC, ISO 8601 and your browser's local time zone.
Seconds vs Milliseconds
Unix timestamps are usually expressed in seconds, for example 1767225600.
JavaScript and some APIs use milliseconds, for example
1767225600000. The two values differ by a factor of 1,000. Mixing them
is one of the most common timestamp bugs: a millisecond value interpreted as seconds
becomes a date tens of thousands of years in the future.
Auto-detect treats values below 100 billion as seconds and larger values as milliseconds. If a value is ambiguous, select the exact input type manually.
How to Convert a Timestamp
- Paste a Unix timestamp or a date string.
- Choose the input type: auto-detect, seconds, milliseconds or date string.
- Select Convert.
- Copy the format you need: Unix seconds, milliseconds, ISO 8601, UTC or local time.
Use the Now button to insert the current Unix time in seconds. The result updates from the current moment.
ISO 8601 and UTC
ISO 8601 is a standard date and time format such as
2026-01-01T00:00:00.000Z. The trailing Z means UTC. ISO
strings are easier to read than raw timestamps and are widely accepted by APIs,
logs and databases. UTC is the same instant everywhere; local time depends on your
browser's time zone and daylight-saving rules.
Date Strings
When “Date string” is selected, the converter passes the value to the browser's
date parser. ISO 8601 strings are the safest choice because they are unambiguous.
Formats such as 01/02/2026 can mean different dates in different
locales; prefer ISO format when exchanging data between systems.
Common Uses
- Debugging API responses and database values.
- Converting log timestamps to readable dates.
- Checking JWT
exp,iatandnbfclaims. - Preparing expiration dates for tokens or scheduled jobs.
- Comparing UTC and local time during incidents.
Common Pitfalls
Time zones
A timestamp represents an instant, not a local clock reading. The same instant can be a different date in UTC and in your local time zone. Always state the time zone when sharing a date with someone else.
Daylight saving time
Local time can jump forward or backward when daylight saving changes. UTC and Unix time do not jump. For scheduling, store instants in UTC and convert for display.
Leap seconds
Unix time ignores leap seconds. For most application timestamps this is irrelevant, but scientific and precision timing systems may need a different representation.
Negative timestamps
Dates before 1970 use negative Unix values. Many converters and APIs handle them, but some systems do not. Verify the behavior of the system you are integrating with.
Epoch Time in Databases and APIs
Databases and APIs do not always agree on units. Some store Unix seconds, others
store milliseconds, and JavaScript's Date uses milliseconds internally.
A timestamp without a documented unit is ambiguous. Store instants in UTC, document
whether the value is seconds or milliseconds, and convert only at the boundaries
where data enters or leaves your system.
For human-facing dates, return an ISO 8601 string or format the date in the user's time zone. Keep the raw timestamp for sorting, comparisons and storage. This avoids daylight-saving edge cases and makes logs easier to correlate across services.
Privacy
Conversion runs locally in your browser. The timestamps and dates you enter are not uploaded or stored. For token inspection, use the JWT Decoder; for formatting the surrounding JSON, use the JSON Formatter.
Related Tools
Generate unique identifiers with the UUID Generator, format data with the JSON Formatter, or decode encoded values with the Base64 Encoder / Decoder.