Zellio.io

Unix Timestamp Converter

Convert between Unix time, ISO 8601 and human dates both ways.

Runs locallyWorks offlineShare link carries settings, never your data
Send output toBase64 Encode / DecodeCode FormatterRegex Tester & BuilderBuild a workflow from thisOutput stays on this page until you send it.

Frequently asked questions

What is a Unix timestamp?

It is the number of seconds (or milliseconds) elapsed since 1 January 1970 UTC — a compact, time-zone-free way for systems to store and exchange time. Unix timestamps (also called epoch time or POSIX time) are independent of timezone and daylight saving changes, making them ideal for logging, scheduling, and international applications. This single reference point (January 1, 1970) is called the Unix epoch, and all times are measured relative to it. Unix timestamps eliminate ambiguity when comparing times across systems and regions, and they're used internally by virtually every operating system and programming language.

Seconds or milliseconds?

Both are supported. Many languages use seconds while JavaScript uses milliseconds; the converter handles either and shows you the date. Unix timestamps in seconds have been the standard for decades and are used in databases, APIs, and system logs. JavaScript and some modern languages use milliseconds for finer granularity (1000 milliseconds = 1 second). The converter automatically detects whether you've entered a seconds or milliseconds timestamp based on magnitude, but you can also specify which one you're working with. This flexibility makes it easy to translate timestamps between different systems that may use different precisions.

Does it handle time zones?

It shows UTC and your local time so you can reason about logs and APIs that record time in UTC. Since Unix timestamps are always in UTC, the converter displays the equivalent time in both UTC and your device's local timezone for easy reference. This dual display prevents confusion when reading server logs, API responses, or database records that typically store time in UTC. You can also set a specific timezone if you're debugging events from a different region, making it easier to understand when a remote user performed an action or when a scheduled job ran.

Pro tips

  • Count the digits before assuming a unit: ten is seconds, thirteen is milliseconds. It is the fastest way to catch the mistake.
  • A date landing in 1970 almost always means milliseconds were read as seconds; one in the far future means the reverse.
  • Store and transmit timestamps in UTC and convert only for display — converting early is what produces off-by-an-hour bugs twice a year.
  • Use ISO 8601 in anything a human will read. Epoch values are efficient and unreadable, and a log nobody can scan costs more than the bytes saved.
  • Watch for dates computed far into the future on 32-bit systems, where 2038 is a live constraint rather than a curiosity.

About Unix Timestamp Converter

Works in both directions, which is exactly what you want when a log line hands you 1735689600 and the bug report hands you a date. Epoch values are also the usual culprit when a record turns up dated 1970.

Convert between Unix epoch time, ISO 8601 and human-readable dates in both directions, including relative time like '3 hours ago'. It is an everyday helper for working with logs, API responses, database timestamps and debugging time-zone issues.

Paste an epoch value to read it as a date, or pick a date to get its timestamp. Both seconds and milliseconds are shown, since APIs disagree about which one they mean by 'timestamp'.

Unix time counts seconds since midnight UTC on 1 January 1970, which makes it compact, timezone-free and naturally sortable — the reasons it appears throughout logs, tokens, databases and APIs. The recurring bug is units: the convention is seconds, but JavaScript, Java and plenty of APIs use milliseconds, and mixing them does not error. It silently produces a date in 1970 or one roughly fifty thousand years out. A quick check is digit count — a current timestamp is ten digits in seconds and thirteen in milliseconds.

Two further properties are worth knowing. A signed 32-bit timestamp overflows on 19 January 2038 and wraps to 1901, which is not a distant problem: any system computing dates decades ahead — a mortgage schedule, a long-dated certificate, a retention policy — can reach it today on 32-bit hardware. And Unix time deliberately ignores leap seconds, so it is not a true count of elapsed seconds. For application work that is exactly what you want; for measuring precise intervals across a leap second it is a documented limitation rather than a bug.

Common use cases

  • Reading a timestamp out of a log line while debugging an incident.
  • Checking a JWT's issued-at or expiry claim to explain an authentication failure.
  • Converting a database column to a readable date without writing a query.
  • Reconciling event times across systems that record in different formats.
  • Working out how long ago something happened from a raw epoch value.
How it comparesepochconverter.com is the long-standing reference and covers more exotic epoch formats. The everyday need is bidirectional conversion with both seconds and milliseconds visible at once, which is what removes the guess about which unit an API meant.