All processing runs in your browser — no files or inputs are uploaded to a server.
A Unix timestamp counts the seconds (or milliseconds, or microseconds, depending on the system) elapsed since 1970-01-01 00:00:00 UTC. That moment is the "Unix epoch" and it was chosen by the AT&T Bell Labs team in the early 1970s — long enough ago that the format was still small, recent enough to leave room before negative dates become awkward. Every clock-aware system in Unix-derived environments ultimately reduces to this scalar.
Two consequences are worth keeping in mind. First, the timestamp ignores time zones. Two machines in Seoul and Los Angeles at the same instant see the same Unix value; only the human-readable rendering differs. Second, leap seconds are not represented: Unix timestamps assume every day is exactly 86,400 seconds, and when the IERS inserts a leap second at the end of a UTC day, the Unix counter quietly repeats or smears that second. POSIX specifies this behavior; most applications do not need to care.
The same moment can show up half a dozen different ways depending on the system you are looking at. Knowing which one you have helps you pick the right parser — and knowing the precision keeps millisecond and microsecond values from being misread as seconds far in the future.
| Format | Example | Precision | Where you see it |
|---|---|---|---|
| Unix seconds | 1747353600 | 1 s | Most databases, JWT exp/iat claims, Unix file modification times. |
| Unix milliseconds | 1747353600000 | 1 ms | JavaScript Date.now(), Java System.currentTimeMillis(), Kafka log timestamps. |
| Unix microseconds | 1747353600000000 | 1 µs | Postgres TIMESTAMP, Python time.time_ns() / 1000, some tracing systems. |
| ISO 8601 | 2025-05-16T00:00:00Z | variable | REST APIs, RFC 3339 (a strict subset), HTML <time>, log formats. |
| RFC 2822 | Fri, 16 May 2025 00:00:00 +0000 | 1 s | Email headers (Date:), HTTP Date header per RFC 9110. |
| JS Date.toString | Fri May 16 2025 09:00:00 GMT+0900 (JST) | 1 s | V8 default — not a standard format, varies by engine; avoid for serialization. |
A timestamp by itself is unambiguous — the same instant everywhere. A wall-clock date like "2025-05-16 09:00" is not; it needs a time zone to fix it on the timeline. The gap between "moment" and "clock face" is where most date bugs live.
UTC offsets like +09:00 are a snapshot of the difference between UTC and local time at one moment. They are not the same as time zones. America/Los_Angeles is a time zone; it switches between -07:00 and -08:00 twice a year. The IANA Time Zone Database (tzdata) encodes every transition for every region back to 1970, and most operating systems and runtimes ship a copy. When you store a moment, store either UTC plus a time zone identifier or a Unix timestamp — never just a wall-clock string. When you format for a user, look up the zone and apply it; the offset they need today is not necessarily the offset they will need next Sunday.
Y2038 is the cousin of Y2K. A 32-bit signed integer holding Unix seconds overflows at 2038-01-19T03:14:07Z; the next second flips to a negative value, which most code reads as 1901. Systems that store seconds in 32 bits — old embedded firmware, some C structs (time_t on 32-bit Linux), older database columns — will misbehave at that moment unless migrated to 64 bits first.
Other rollover deadlines lurk in adjacent formats. GPS week numbers used a 10-bit counter that rolled over in 1999 and again in 2019. NTP's 32-bit seconds counter overflows in 2036. Windows FILETIME uses 100-nanosecond ticks from 1601-01-01 and is safe until the year 30828. JavaScript's Number can represent integers exactly up to 2^53 milliseconds, which is roughly the year 287396 — comfortably safe but worth being explicit about if you write your own arithmetic. Audit what stores time, find anything still using 32-bit seconds, and migrate before the deadline rather than during the incident.
First, seconds versus milliseconds. A value of 1747353600 is May 2025; the same digits with three more zeros (1747353600000) are also May 2025 but in milliseconds. Swap them and you land in the year 57344. The tool above auto-detects by magnitude; in your own code, be explicit about which unit any timestamp uses.
Second, JavaScript Date months are zero-indexed. new Date(2025, 5, 1) is June 1, not May 1. Use ISO strings or libraries like date-fns / Luxon to avoid this trap entirely.
Third, "midnight" is ambiguous. 00:00:00 in local time is not the same instant as 00:00:00 UTC unless you happen to be on UTC. For daily reports, decide whether the boundary is local-midnight or UTC-midnight up front, and write it down in the spec.
Fourth, DST and historical zone changes. Iterating "add one day" 365 times across a DST boundary will land you an hour off. Use a library's timezone-aware arithmetic instead of raw millisecond math. Historical changes are real too — Russia abolished DST in 2011 and brought it back in 2014; Turkey kept it permanently in 2016. tzdata captures these.
Fifth, microsecond precision is lossy. JavaScript's Date has 1 ms resolution; serializing a Postgres TIMESTAMP via JavaScript truncates the trailing microseconds silently. For high-precision telemetry, keep the full-precision value as a string or BigInt in transit and only convert at the presentation layer.
Paste a Unix timestamp (seconds or milliseconds), an ISO 8601 string, an RFC 2822 date, or any string `new Date()` understands. The tool detects the format and shows seven equivalent views at once: Unix seconds, Unix milliseconds, ISO 8601 in UTC, ISO 8601 in your local timezone, a human-readable UTC line, a human-readable local line, and a relative time that ticks live (e.g., "3 minutes ago").
The Now button drops the current Unix-second value into the input. Seconds vs. milliseconds detection is by magnitude: anything ≥ 10^12 is treated as ms, so 10-digit values are seconds and 13-digit values are ms — the threshold lasts until year 33658, more than enough margin. Conversions run entirely in the browser through the JavaScript Date and Intl APIs, no server round-trip.
1716800400
Unix sec: 1716800400 Unix ms: 1716800400000 UTC: 2024-05-27T09:00:00.000Z Local: 2024-05-27T18:00:00+09:00 (Asia/Tokyo) Relative: about 2 years ago
Most server logs (nginx, syslog, application timestamps from `time.Now().Unix()` in Go or `time.time()` in Python) emit seconds. The local view applies your browser's timezone — handy when correlating logs from a server in a different region.
1716800400000
Unix sec: 1716800400 Unix ms: 1716800400000 UTC: 2024-05-27T09:00:00.000Z
JavaScript `Date.now()`, Java `System.currentTimeMillis()`, and most JSON APIs emit milliseconds. The 13-digit length triggers ms detection; the same moment in seconds is the 10-digit form. No need to remember which unit you have — paste and look.
2024-05-27T18:00:00+09:00
Unix sec: 1716800400 UTC: 2024-05-27T09:00:00.000Z Local: 2024-05-27T18:00:00+09:00
When the input carries an offset, parsing is unambiguous — no timezone guessing. A bare `2024-05-27 18:00:00` would be read in the browser's timezone instead. Prefer the explicit offset (or trailing `Z` for UTC) in API contracts.
By magnitude. Values ≥ 10^12 are read as milliseconds; smaller numeric inputs are read as seconds. The threshold corresponds to year 33658 in seconds, so any timestamp from this century is unambiguous. If you really need to force one unit, append `000` to push a seconds value into the ms band, or divide a ms value externally.
Y2038 is the overflow of signed 32-bit Unix timestamps at 2038-01-19 03:14:07 UTC — they wrap to 1901. This tool uses JavaScript Numbers (53-bit safe integer range) for seconds and milliseconds, so the conversion itself has no 2038 boundary. The risk lives downstream: if you feed a > 2^31 value to a C program using `time_t` on a 32-bit platform, it will misread it. Convert and store as 64-bit (`int64`, `BIGINT`) end to end.
RFC 3339 is a strict subset of ISO 8601 aimed at internet protocols. ISO 8601 allows several optional shapes (basic format without dashes, week dates, ordinal dates, comma decimal separators). RFC 3339 narrows that down: extended format only, `T` or space between date and time, mandatory offset, dot decimal. JavaScript's `Date` parser accepts the RFC 3339 form reliably; some ISO 8601 variants will fail. When designing an API, write "RFC 3339" instead of "ISO 8601" to avoid the looser interpretations.
A Unix timestamp is a single instant. The same instant is "today" in Tokyo and "yesterday" in New York simultaneously — that's the point of having both views. If a server log says `1716800400` and your dashboard shows `2024-05-27 18:00 JST`, a colleague in California sees `2024-05-27 02:00 PDT` for the same row. Always pair a timestamp with its rendering rule (UTC vs. local vs. fixed zone) when discussing it.
Yes — negative Unix timestamps work. `−1` is 1969-12-31T23:59:59Z. Paste an ISO 8601 string like `1969-06-20T20:17:40Z` (Apollo 11 lunar landing) and you'll get its negative Unix value. JavaScript Date handles roughly ±100 million days from the epoch, so any historical or far-future date you encounter in normal work parses fine.
Unix time treats every day as exactly 86400 seconds and silently skips leap seconds; GPS time does not. As of mid-2026 the cumulative offset is 18 seconds (Unix lags GPS by 18). For nearly all software this is invisible because both ends use Unix time. The discrepancy only matters when interfacing with GNSS receivers, astronomical software, or legacy systems that store TAI / GPS time.
A Unix timestamp is the number of seconds since 1970-01-01T00:00:00 UTC, treating every day as 86400 seconds (so leap seconds are silently skipped). The same instant rendered in calendar form requires three additional pieces of information: a calendar (Gregorian), a timezone (offset from UTC, often with DST rules), and a locale (for the language and ordering of "May" vs. "5월" vs. "5月"). The tool shows all three layers side by side so it stays clear which is the absolute moment and which are the rendering choices.
Units matter more than people expect. Unix seconds use 10 digits today; milliseconds use 13; microseconds (common in databases and some logging frameworks) use 16; nanoseconds (Go's `time.Now().UnixNano()`, modern syslog) use 19. Mistaking units is the most common timestamp bug — a "ms" field read as "sec" lands you 52,000 years in the future, while a "sec" field read as "ms" lands in January 1970. The 10-vs-13 magnitude check this tool uses works for current timestamps; for high-precision sources you may need explicit conversion.
Three adjacent standards are worth knowing. **ISO 8601** is the broad calendar/date standard with many optional forms (`2024W221`, `2024-148T18:00:00`). **RFC 3339** is the strict subset used by internet protocols — what most API docs actually mean when they say "ISO 8601". **TAI** is the underlying atomic time scale that does count leap seconds, so it now leads Unix time by 18 seconds; the difference matters for GNSS, astronomy, and any system synchronized with `chrony` in TAI mode.
Format and validate JSON. Indented or minified output, with clear error messages.
Encode text to Base64 or decode Base64 back to text. UTF-8 safe.
Percent-encode or decode URL components.
Decode JWT header and payload locally. Signature is not verified — paste tokens at your discretion.
