Timestamp Converter
Auto-detects Unix timestamps (s, ms, µs, ns) and date strings. Shows ISO 8601, RFC 2822, timezone-adjusted times, and relative age. Bidirectional, browser-only.
tz:
input
Paste any timestamp or date to see all its representations. Click to insert the current time.
// how to use
Convert any timestamp in seconds.
- 01Paste anything that resembles a timestamp.Unix seconds (10 digits), milliseconds (13), microseconds (16), nanoseconds (19), or any date string the browser can parse — ISO 8601, RFC 2822, or natural language like “April 27 2026”. The tool detects the format.
- 02Choose a timezone.UTC by default for unambiguous output. Switch to your browser's local timezone or one of the common IANA zones to see what the moment looks like in that location.
- 03Read or copy any representation.ISO 8601, RFC 2822, Unix integers at every precision, relative age (“3 hours ago”), and day of year. Hover any row to copy.
// background
Why timestamps need conversion at all.
A Unix timestamp is conceptually simple: a single integer counting seconds (or milliseconds, or…) since midnight UTC on January 1, 1970 — known as the “Unix epoch”. It's timezone-agnostic, sortable, compact, and exactly represents an instant in time without ambiguity.
The complications come from two places: the unit (different languages and APIs use different precisions) and the display (humans want to see local time, but the timestamp itself doesn't store that). This tool handles both.
The four common precisions
seconds10 digitsUnix shell, C time_t, JWT exp/iatmilliseconds13 digitsJavaScript Date.now(), most web APIsmicroseconds16 digitsPython time.time() * 1e6, MySQL DATETIME(6)nanoseconds19 digitsGo time.UnixNano(), gRPC, ClickHouseCommon pitfalls
- →Mixing units: storing milliseconds in a column expecting seconds gives dates ~50,000 years in the future
- →Assuming local time: most APIs return UTC; converting on the client is your responsibility
- →DST transitions: '2:30 AM on the spring-forward day' may not exist; libraries handle this differently
- →Y2K38: 32-bit signed timestamps overflow on January 19, 2038 — relevant only for legacy systems
- →Leap seconds: Unix timestamps don't represent them; almost never matters but can throw off scientific code
When you'll need this tool
- →Reading server logs that print Unix timestamps
- →Debugging a JWT token with exp / iat / nbf claims
- →Inspecting database rows with epoch timestamps
- →Reading a webhook payload from Stripe, GitHub, or Slack
- →Converting between APIs that disagree on precision
- →Quick sanity-check: is this number 'now-ish' or way off?
// faq
Frequently asked questions.
What's the difference between seconds, milliseconds, microseconds, and nanoseconds?+
All represent the time elapsed since the Unix epoch (Jan 1, 1970 UTC), but with different precision. Seconds is the original Unix format (used in C, shell scripts). Milliseconds is the JavaScript default (Date.now() returns ms). Microseconds shows up in Python's time.time_ns() / 1000 and high-resolution APIs. Nanoseconds is common in Go, gRPC, and database timestamp columns. The tool auto-detects which one you pasted based on the digit count.
Why does the same timestamp show different times in different timezones?+
A Unix timestamp is timezone-agnostic — it's the absolute number of seconds since the epoch in UTC. When you display it as a date, the timezone determines what wall-clock time that absolute moment maps to. The instant 1714237200 is the same moment everywhere, but it's 5pm in London, noon in New York, and 9pm in Dubai. The tool defaults to UTC for unambiguity, but you can switch to your local zone or any IANA timezone.
What's ISO 8601 and why is it preferred?+
ISO 8601 is the international standard for representing dates and times as strings (e.g., 2026-04-27T14:00:00Z). It's preferred because it's unambiguous (no '04/27' vs '27/04' confusion), sortable as text, includes timezone info, and is universally parsed by every major language and database. RFC 3339 is a slightly stricter subset of ISO 8601 used in HTTP and APIs.
What's the Y2K38 problem?+
On systems that store Unix timestamps in 32-bit signed integers, the maximum representable value is 2,147,483,647 — which corresponds to January 19, 2038, 03:14:07 UTC. Past that moment, those systems will overflow and likely interpret times as 1901. Most modern systems use 64-bit timestamps and are fine, but legacy code (some embedded systems, old C programs, specific database columns) may still be at risk. If your code reads or writes timestamps as int32, you should migrate before 2038.
Can I parse formats like '04/27/2026' or '27-04-2026'?+
The tool uses JavaScript's Date.parse() under the hood, which handles ISO 8601, RFC 2822, and many common variations — but ambiguous formats like '04/27/2026' (US-style) vs '27/04/2026' (most of the world) may parse differently in different browsers, or fail. For reliability, prefer ISO 8601 input. If you have a non-standard format, convert it to ISO first or use a dedicated parsing library.
Does this work offline?+
Yes, completely. All parsing and formatting happen in your browser using the built-in Date and Intl APIs. Once the page is loaded, no further network requests are made for the conversions. You can verify in the network tab of devtools.
// related