Unix timestamp converter

Convert Unix seconds or milliseconds to UTC dates and back.

Your files are processed here, on your device

We do not send your file or text contents to a processing server. No account is needed and there is no daily operation quota. Individual tools have size limits to protect your device’s memory.

A connection is needed to load the site and its resources. Hosting may receive technical visit data. Favorites store only tool identifiers in this browser.

How we handle your data →

How to use this tool

  1. Choose timestamp to date or ISO date to timestamp.
  2. Select seconds or milliseconds; include Z or a timezone offset for date input.
  3. Check the resulting UTC date before interpreting it as local time.

An example you can verify

Check a technical log date without timezone ambiguity.

Example input

0

SettingsTimestamp → UTC date. Unit: seconds.

Expected result

1970-01-01T00:00:00.000Z

Do not confuse seconds with milliseconds. Include Z or a timezone offset when converting an ISO date.

Unix timestamp converter: uses and practical guidance

A Unix timestamp represents an instant as an amount of time since the system’s reference epoch. Converting it into a readable date helps inspect logs, API responses and technical data. Identify the unit first: seconds and milliseconds are not interchangeable. Interpreting a value on the wrong scale can produce a date far from the expected one even when the number is syntactically valid. The source field definition is therefore important.

The tool displays the date in UTC. UTC and local time may show different hours while describing the same instant when the correct zones are applied. Include Z or an explicit offset when converting an ISO date to a timestamp. A date and time without a zone is ambiguous and can vary with device settings or seasonal clock changes. The form therefore requires a representation identifying the relevant offset rather than silently guessing a local zone.

Review the source when a value appears unusual. A numeric string might be an identifier rather than a timestamp. Digit count can provide a clue, but does not replace documentation of the field. Negative values represent instants before the epoch under the selected scale. If a destination expects whole seconds, determine how fractions from a millisecond input should be handled instead of discarding them without checking its requirements.

Validate by converting back using the same unit. Compare the instant rather than just written hours in two different zones. Save unit and timezone information alongside the value when preparing examples or exports. Days between dates measures calendar day separation and answers a different question from representing an exact instant. Keeping those purposes separate avoids interpreting a timestamp conversion as a calendar duration calculation.

A practical check before using the result

For a log review, use a known date from the same source to confirm seconds versus milliseconds. Then check a sample containing a timezone offset. Readable representations of one instant can show different hours without being incompatible. Keep timezone information with the example. Document whether exchanging applications expect fractions or integers as well. A consistent timescale prevents errors that look like date problems but originate in units. Inspect the receiving system’s limits because a number accepted by this converter does not prove another API accepts the same range. Retaining source field meaning makes later troubleshooting more reliable than guessing solely from the number of digits.

Settings and limits

Unix measures time from 1970-01-01T00:00:00Z. Choose the direction and unit. Date input must include Z or an offset such as +02:00. Output dates always show UTC.

Frequently asked questions

How do I avoid timezone ambiguity?

Specify the zone. 2026-10-12T14:00:00+02:00 equals 2026-10-12T12:00:00Z. A local time without a zone is rejected.