Skip to content

Unix Timestamp Converter

Convert Unix timestamps to readable dates and back, with auto-detection of seconds vs milliseconds and a live current timestamp.

In your browser—your files never leave your device.

Learn more
Current Unix Timestamp · UTC+03:001779123488
⌘K focus

About this tool

A Unix timestamp counts seconds since January 1, 1970 UTC — the Unix epoch. Almost every system stores time as an integer offset from that moment, but the unit varies: classic Unix uses seconds (a 10-digit number around 1.7 billion in 2026), JavaScript Date.now() uses milliseconds (13 digits, ~1.7 trillion), some databases use microseconds (16 digits), and others store it as a 64-bit nanosecond count (19 digits). This tool converts in both directions and auto-detects the unit by length — if your input is 13 digits or more it is treated as milliseconds, otherwise seconds. Output includes UTC, your local timezone, ISO 8601 (the format you want in JSON), and a relative description ("3 hours ago"). A live counter at the top shows the current Unix time, refreshed every second.

How to unix timestamp converter

  1. Pick a direction

    Use the timestamp input to convert epoch to date. Use the date input to convert date to epoch. Both work independently and simultaneously, so you can have both filled with different values to compare.

  2. Paste or type

    For timestamp input, either 10-digit seconds, 13-digit milliseconds, or any length number — the tool auto-detects which based on the digit count. For date input, use the date/time picker which respects your local timezone.

  3. Read all four formats

    UTC, local time, ISO 8601, and relative time appear simultaneously. Pick the one your destination expects. ISO 8601 is almost always the right answer for new code; local time is for human display; UTC is for log correlation; relative is for "is this recent?" sanity checks.

  4. Copy

    Each output has a copy button. One click sends it to your clipboard. The Clipboard API works on all modern browsers including mobile.

Why use this tool

API debugging is the everyday case. A JWT carries exp as a Unix timestamp and I need to know whether it died half an hour ago or expires next week. Stripe webhooks carry created as seconds-since-epoch and I want to know when the event fired in my local timezone. Database rows store updated_at as either a TIMESTAMP or an integer, and the answer to "when did this last change" needs human-readable format. The second case is generating future dates: "I need a timestamp 7 days from now for a token TTL" — typing the date in and copying the seconds out is one click. The third case is the Year 2038 problem — 32-bit signed integers overflow on January 19, 2038, and any legacy system using INT for timestamps will roll over to a negative number and start mis-displaying dates. This tool handles dates well past 2038 because JavaScript uses 64-bit doubles for milliseconds. The fourth case is debugging log timestamps that arrive in different formats from different systems — Postgres might emit ISO 8601 with timezone, Linux syslog gives you epoch seconds with microsecond precision, application logs might write Unix milliseconds. Normalizing in your head is annoying; pasting and reading is fast.

Features

Bidirectional conversion

Paste a timestamp and get a date, or pick a date and get a timestamp. The two input fields are independent so you can convert in both directions in the same session without losing your previous work. The conversion is symmetric — round-tripping a timestamp through to a date and back gives you the same value, modulo any precision loss at the millisecond boundary.

Auto-detect seconds vs milliseconds

A 10-digit input is treated as Unix seconds. A 13-digit input is treated as Unix milliseconds. This is the unit convention almost everyone uses — current Unix seconds is around 1.75 billion (10 digits, will be until November 2286), current Unix milliseconds is around 1.75 trillion (13 digits, will be until October 4660 AD). The auto-detection is by length, not by value, so a 1-second-since-epoch input (8 digits, year 1970) gets interpreted correctly as seconds, not as 1 millisecond.

Multiple output formats

For a given timestamp you see UTC (the canonical reference), your local timezone (what your users see), ISO 8601 (what your JSON should use), and a relative description ("3 hours ago", "in 5 days"). Each has its own copy button. The variety means whichever format your downstream consumer wants, you can grab it without doing a format conversion separately.

Live current timestamp

A counter at the top shows the current Unix time in seconds, updating every second. Click to copy. Useful when you need "right now" as a timestamp for a token, a log entry, a test fixture, or a database INSERT. The live update means you do not paste a stale value from earlier in your session.

Anchored to a known epoch

Every conversion this tool does is anchored to the Unix epoch: January 1, 1970, 00:00:00 UTC. That moment is timestamp zero. Negative numbers represent times before the epoch (yes, you can paste -86400 and get December 31, 1969). The Unix epoch is the most widely used time origin in computing, but not the only one — Windows FILETIME counts 100-nanosecond intervals since January 1, 1601; NTP counts seconds since January 1, 1900; Apple Cocoa uses January 1, 2001. If a timestamp from another system seems to be off by decades, check whether it is using a different epoch and apply the offset. The tool only handles Unix epoch directly; for other epochs, do the math in your head or your editor.

Privacy & security

All conversions are arithmetic on numbers and string formatting on the results — JavaScript's Date object handles it in your browser. The current timestamp ticker reads Date.now() once a second; your local timezone comes from Intl.DateTimeFormat which inherits from your OS. Nothing leaves the page. Useful for debugging timestamps that ride alongside identifying information (user IDs in log entries, session times in audit trails) since the surrounding context stays in your tab.

Frequently asked questions

Why is the current timestamp 10 digits and not 13?
The tool defaults to displaying Unix seconds (10 digits in 2026) because that is the classic Unix format and what most APIs use. JavaScript Date.now() returns milliseconds (13 digits), so you multiply by 1000 to convert from seconds to milliseconds. PostgreSQL extract(epoch from now()) returns seconds; Python time.time() returns seconds as a float; Go time.Now().Unix() returns seconds. Different stacks default to different units; check your target before pasting a 13-digit number into a field expecting 10.
What is the Year 2038 problem?
A signed 32-bit integer can hold values up to 2,147,483,647. As a Unix timestamp in seconds, that maxes out at 03:14:07 UTC on January 19, 2038. Older systems that store timestamps in INT will overflow and wrap to negative numbers, mis-displaying dates as 1901. The fix is to use BIGINT (64-bit) or to use ISO 8601 strings. Modern systems mostly migrated years ago — anything written this decade is fine. Embedded systems, old databases, and some C code on 32-bit systems are still at risk. This tool uses JavaScript numbers (64-bit floats), which handle dates well past 2038 — you can paste a future timestamp and it converts correctly.
How does this handle timezones?
Internally, everything is UTC — Unix timestamps are timezone-independent by definition, they are just a count of seconds since a fixed reference moment. The display shows both UTC (the canonical reference) and your browser's local timezone (read from your OS via the Intl API). When converting a date to a timestamp, the date you pick is interpreted in your local timezone and converted to UTC seconds internally. So if you are in PST and pick "2026-05-15 09:00", the timestamp represents 09:00 PST = 17:00 UTC, and the timestamp is the same regardless of where the next reader is.
Daylight saving time?
Unix timestamps do not change at DST transitions — they are a continuous count of seconds. Your local-time display does change because your timezone shifts ±1 hour at the spring-forward and fall-back. A timestamp from 2 AM on the day clocks "fall back" can map to two different local times (the first 2 AM and the second 2 AM, an hour apart in UTC), which is why DST-aware date pickers display them with timezone offsets to disambiguate. Stick to UTC for storage; convert to local for display.
Why does my timestamp seem off by a few hours?
Almost always a seconds-vs-milliseconds confusion or a timezone misread. 1700000000 in seconds is November 14, 2023, 22:13 UTC; 1700000000 in milliseconds is January 20, 1970, 00:13:20 UTC. The 10/13-digit auto-detection usually catches this. The other common case is interpreting a UTC timestamp as if it were local time — always check which timezone your source is in. If you see "your timestamp" off by exactly your local UTC offset, that is the problem.
What is ISO 8601?
The international standard for date-time strings: YYYY-MM-DDTHH:MM:SS.sssZ where Z means UTC, or with a ±HH:MM suffix for explicit offsets. Example: 2026-05-15T14:30:00Z. It sorts correctly as a string (lexicographic order = chronological order for ISO 8601 strings of the same timezone), is unambiguous (no MM/DD vs DD/MM confusion that plagues US-vs-European date formats), and is what every modern API should use in JSON. The Z suffix is shorthand for +00:00 and the format is what JavaScript Date.toISOString() emits.
Relative time accuracy?
Computed against the current moment when you paste the timestamp. "3 minutes ago" is accurate at the second you read it; refresh after a minute and the description rolls forward. For long-lived display in a UI you would want a live-updating component (date-fns/formatDistanceToNow with a setInterval, for example), but for a quick "is this stale?" check, the snapshot is plenty. The granularity is seconds, minutes, hours, days, months, years — no sub-second display.
What is the highest-precision timestamp I can paste?
The tool handles up to milliseconds (13 digits). For microseconds (16 digits, what Postgres returns from EXTRACT(EPOCH FROM column)*1000000) or nanoseconds (19 digits, what some Go programs emit), the auto-detection falls back to interpreting as milliseconds, which gives wrong results. Divide by 1000 or 1,000,000 before pasting to get the millisecond form. For sub-millisecond precision in JavaScript, you usually do not need it — Date.now() is millisecond-precision and that is fine for almost all use cases.
Privacy?
Pure computation in the browser, no network calls. The current time is read from your system clock via Date.now(). The timezone is read from your browser via Intl.DateTimeFormat. None of it leaves the page. Useful when you are debugging timestamps from internal systems that contain identifying information in adjacent fields.
Why does Unix time ignore leap seconds?
Because Unix time was designed before leap seconds were a thing, and changing the rule later would break decades of code. A Unix timestamp says "this many seconds have elapsed since the epoch" but the seconds it counts are not all the same length as real seconds — when the IERS announces a leap second (which has happened 27 times since 1972, most recently in 2016), the world's atomic clocks add an extra second to keep civil time aligned with Earth's rotation, but Unix systems mostly do not. The standard behavior is to either repeat the same Unix timestamp twice for two real seconds (a "smeared" leap second), or to step the clock back by one second at the moment of insertion. Google smears leap seconds over a 24-hour window so no second has the same timestamp twice. The practical consequence: for sub-second-precision logging or financial timestamps, leap-second-aware time formats exist (TAI, GPS time), but for almost every application the Unix simplification is fine. There is a proposal to abolish leap seconds entirely by 2035, which would close this gap permanently.
Microseconds, nanoseconds, and the unit confusion in modern systems
A timestamp in seconds has 10 digits in 2026 (1,750,000,000-ish). In milliseconds it has 13 digits (1,750,000,000,000). In microseconds, 16 digits (1.75 × 10^15). In nanoseconds, 19 digits (1.75 × 10^18). Different stacks default to different units: Postgres SELECT EXTRACT(EPOCH FROM NOW()) returns seconds as a float; Postgres SELECT NOW() returns a TIMESTAMPTZ that pretty-prints as ISO 8601; Go time.Now().UnixNano() returns nanoseconds as an int64; Python time.time_ns() returns nanoseconds as an int (added in 3.7); Rust SystemTime::now().duration_since(UNIX_EPOCH) returns a Duration you can ask for nanos or seconds. The tool auto-detects between seconds (10 digits) and milliseconds (13 digits) but treats microsecond and nanosecond inputs as oversized millisecond values, which is wrong. Divide microseconds by 1000 or nanoseconds by 1,000,000 before pasting to get the correct conversion.
ISO 8601 versus RFC 3339 — are they the same thing?
Close cousins, not identical. ISO 8601 is a broader, older standard that allows many date-time forms — basic format with no separators (20260515T143000), extended format with separators (2026-05-15T14:30:00), date-only forms, ordinal dates (2026-135 for the 135th day of 2026), week dates (2026-W20-3). RFC 3339 is a tighter profile of ISO 8601 specifically designed for the Internet, mandating the T separator, requiring a timezone offset (or Z for UTC), and forbidding the more exotic ISO 8601 variants. Anything that follows RFC 3339 also follows ISO 8601, but not the reverse. In practice, when an API says "ISO 8601", it usually means RFC 3339 — the format JavaScript Date.toISOString() emits (2026-05-15T14:30:00.000Z) is RFC 3339 compliant. The places where the difference matters: parsing log files from heritage systems that emit ISO 8601 basic format without separators, or rejecting strings that omit the timezone offset (RFC 3339 forbids this, ISO 8601 allows it).
What are the common DST traps when storing timestamps?
Three traps catch most teams. First trap: storing local-time strings instead of UTC. When clocks fall back in autumn, the hour from 1:00 AM to 2:00 AM happens twice in local time. A row stamped "1:30 AM" is ambiguous — which 1:30 AM? The standard fix is to always store UTC and convert for display. Second trap: scheduling jobs at local times across DST transitions. A cron job scheduled to run at 2:30 AM local will either run twice (in fall) or not at all (in spring) on the transition day, depending on how your cron implementation handles non-existent times. Use UTC for cron schedules and let the display layer translate. Third trap: comparing two local-time strings as text. "2026-03-08T01:30:00" sorted lexically against "2026-03-08T03:30:00" gives the right order, but only because the day did not span a DST boundary in that comparison. Across a transition, local-time-sorted timestamps lie about real elapsed duration. UTC-only storage avoids all three; convert to local timezone only at the very last step before showing the value to a human.