Free Unix Epoch Timestamp Converter

What Unix Epoch Time Actually Is

Unix epoch time (also called POSIX time, Unix time, or just "epoch") is a system for representing instants in time as a single integer: the number of seconds (or milliseconds, in JavaScript and many modern systems) elapsed since the Unix epoch at 00:00:00 UTC on 1 January 1970. Negative numbers represent times before the epoch; positive numbers, times after. The single-integer representation has compelling properties: it's timezone-independent (the number is the same anywhere on Earth at the same instant), it's easy to compare (later times are larger numbers), and it's trivial to compute durations (subtraction). Unix time is the underlying time representation in essentially every operating system, every database engine, every API protocol, and every programming language standard library, even systems whose user interfaces show calendar dates store the underlying values as epoch integers.

The Choice of 1 January 1970, and Other Epochs

The 1970-01-01 epoch dates from the early days of Unix at Bell Labs. Unix's time_t type was originally a 32-bit signed integer counting seconds from a chosen baseline; the team picked the most recent New Year before development started, which was 1 January 1970. The decision was practical, not philosophical, Unix was being developed in 1969-1971, and a recent epoch maximised the usable range of timestamps within the 32-bit signed range. Other systems chose other epochs that suited their use cases. NTP (Network Time Protocol, RFC 5905) uses 1 January 1900 as its epoch, important because NTP needed to span longer historical ranges. Windows FILETIME uses 1 January 1601 as a 100-nanosecond-tick epoch (the start of the 400-year Gregorian cycle that included 1601). VAX/VMS used 17 November 1858 (the modified Julian Day epoch, popular in astronomy). Mac classic used 1 January 1904. JavaScript Date uses Unix epoch but counts milliseconds rather than seconds (a 64-bit float, giving ±100 million years of usable range). The takeaway: Unix epoch is dominant in 2026, but the historical record contains many other choices, each with its own backwards-compatibility legacy.

The Y2K38 Problem, Unix Time Will Run Out (Sort Of)

If time_t is a 32-bit signed integer (the original Unix design), the maximum representable timestamp is 2,147,483,647, which corresponds to 03:14:07 UTC on Tuesday, 19 January 2038. One second later, the value overflows to negative, wrapping around to 13 December 1901. This is the Y2K38 problem (also called the Epochalypse). On modern 64-bit systems, time_t is a 64-bit signed integer and the overflow date is 4 December 292,277,026,596, comfortably past the death of the sun. But 32-bit embedded systems are still in active deployment in industrial controllers, satellites with long missions, banking back-end systems, oil-and-gas SCADA networks, automotive infotainment, and IoT sensors with multi-decade design lifetimes. The mitigation has been ongoing since the early 2000s, every major OS, database, and language now defaults to 64-bit time on 64-bit hardware (Linux completed the transition in kernel 5.6, March 2020; Windows always used 64-bit; macOS Catalina dropped 32-bit support in 2019). Embedded systems are the long tail. The Y2K38 problem will not be a single-day crisis like Y2K was; it will be a series of small failures in long-tail systems over the years approaching 2038, exactly the way Y2K manifested mostly in obscure systems that nobody had patched.

ISO 8601, The Other Standard Time Format

Where Unix time is the wire format, ISO 8601 is the human-readable format. Originally published as ISO 8601:1988, revised in 2000, 2004, and most recently in ISO 8601-1:2019 and ISO 8601-2:2019, the standard defines representations like 2026-05-03T14:30:00Z (with the Z meaning UTC) or 2026-05-03T14:30:00+01:00 (with the explicit offset). The "T" separates the date from the time; the trailing offset disambiguates the timezone. For internet protocols, RFC 3339 (Klyne and Newman, 2002) defines a strict subset of ISO 8601 that's easier to parse, it's the format you'll see in JSON API responses, log timestamps, JWT exp/iat fields, and OAuth flows. The relationship to Unix time: ISO 8601 is the human-readable form of an instant; Unix time is the integer form of the same instant. A converter like this one moves between them in either direction. The local-time form (2026-05-03T14:30:00 with no offset) is ambiguous and should be avoided in any system that crosses time zones, it's frequently the source of subtle bugs where a JSON API claims to return timestamps but doesn't say what timezone they're in.

Seconds vs Milliseconds, The Common Confusion

Unix time at the operating-system level counts seconds: a 10-digit integer for any time between roughly 2001 and 2286 (timestamps before 2001 had 9 digits or fewer). JavaScript's Date.now(), the JVM's System.currentTimeMillis(), .NET's DateTimeOffset.ToUnixTimeMilliseconds(), and most web APIs count milliseconds: a 13-digit integer for the same range. The two forms differ by exactly a factor of 1,000, and the most common timestamp-related bug in any code that talks to multiple systems is feeding a milliseconds value into a function expecting seconds (giving a date 1,000× further in the future than intended) or vice versa (giving a date a fraction of a second after the epoch). This converter auto-detects based on the digit count: 10 or fewer digits = seconds, 13 or more = milliseconds. For values in between (11–12 digits, ambiguous), the converter prefers the interpretation that gives a sensible date. Microseconds (16 digits, used by some high-precision systems and many database TIMESTAMP types) and nanoseconds (19 digits, used by Linux clock_gettime, Go's time.UnixNano(), modern observability tooling like OpenTelemetry) are also encountered but are less common in user-facing data.

Where You Actually Need This Conversion

• Reading API responses. A REST endpoint returns "created_at": 1714665600: what date is that? Paste, see "May 2, 2024 16:00:00 UTC", move on with the debug session. Stripe, GitHub, AWS, and most enterprise APIs use Unix-time integers for date fields specifically to avoid timezone ambiguity.
• Decoding log timestamps. Server logs often record times as Unix integers for compactness and parsing speed. Reading "1714665600.234 ERROR connection refused" requires converting the leading number to a calendar time to correlate with other events.
• JWT debugging. The exp (expiration) and iat (issued-at) claims in JSON Web Tokens are Unix-time integers per RFC 7519. To check whether a token is expired or to see when it was issued, paste the value here.
• Time-difference calculation. Subtract two Unix timestamps to get the duration between them in seconds (or milliseconds). No timezone math, no DST adjustment, no calendar-arithmetic edge cases.
• Database queries with epoch columns. Many older databases store timestamps as Unix integers. Querying "all events between X and Y" requires converting human-readable cutoff dates to Unix integers for the WHERE clause.
• Scheduling and cron tasks. Systems that schedule jobs by absolute time (Kubernetes CronJobs, AWS EventBridge, Azure Logic Apps) often want Unix-time targets in their configuration. Convert the human-friendly target time to epoch.
• Decoding "interesting" timestamps. Famous epoch values: 0 = 1 January 1970 00:00:00 UTC (the epoch itself); 1234567890 = 13 February 2009 23:31:30 UTC (briefly celebrated as the "Unix billion" moment); 1500000000 = 14 July 2017 02:40:00 UTC; 2000000000 = 18 May 2033 03:33:20 UTC; 2147483647 = 19 January 2038 03:14:07 UTC (the Y2K38 overflow point).

A Note on Leap Seconds and "Real" Time

A subtle complication: Unix time as defined by POSIX does not include leap seconds. Coordinated Universal Time (UTC) occasionally adds a leap second to keep civil time aligned with Earth's actual rotation, 27 leap seconds have been added since the system began in 1972. Unix time pretends those leap seconds didn't happen: when a leap second is inserted at the end of a day, the clock either repeats the last second (Linux's traditional behaviour) or smears it over a longer period (Google's "leap smear" approach, adopted by AWS and many CDNs). For most application use, this doesn't matter, sub-second time accuracy is rarely meaningful at the application level. For high-precision scientific work, financial trading-system timestamps, or legal-evidentiary timestamps, the leap-second behaviour is a known source of edge cases. The IERS (International Earth Rotation and Reference Systems Service) announces leap seconds with six months' notice; the most recent was inserted at the end of 31 December 2016, and the international community has been considering retiring leap seconds entirely (the resolution to do so by 2035 was adopted at the 2022 General Conference on Weights and Measures).

Privacy: Browser-Only Conversion

Timestamps you paste are usually not sensitive in themselves (a Unix integer reveals only an instant in time), but the context, a log line containing a real user identifier alongside the timestamp, a JWT containing claims about a real user, an API response with internal entity IDs (frequently is. This converter runs entirely in your browser via JavaScript's built-in Date API. No upload, no logging) verify in DevTools' Network tab while you type a timestamp (no requests fire), or take the page offline (airplane mode) after it loads. The live-updating "now" display uses your local clock, not a network time source.

Frequently Asked Questions

What is a Unix timestamp?

A Unix timestamp (also called Epoch time or POSIX time) is the number of seconds elapsed since 1 January 1970 at 00:00:00 UTC, treating Unix's POSIX abstraction (which doesn't count leap seconds) rather than true elapsed atomic-clock seconds. Many modern systems use milliseconds rather than seconds for sub-second precision (JavaScript's Date.now(), Java's System.currentTimeMillis(), .NET's DateTimeOffset.ToUnixTimeMilliseconds()). Unix time is the standard time representation in essentially every operating system, database, and web API.

What's the difference between seconds and milliseconds?

A factor of 1,000. Seconds-precision Unix timestamps in 2026 are 10 digits (e.g., 1714665600); milliseconds-precision are 13 digits (e.g., 1714665600234). This converter auto-detects based on digit count. The most common bug in code that mixes the two forms is feeding milliseconds into a function expecting seconds (giving a date 1,000× further in the future than intended) or vice versa.

Why is my converted time off by hours?

Unix time is timezone-independent, but the human-readable form depends on which timezone you display it in. The converter shows three formats simultaneously: Local Time (your browser's timezone), UTC (Greenwich), and ISO 8601 (with explicit offset). If the result doesn't match what you expected, check the timezone, your "expected" value was probably in a different timezone than the format you read.

What's the Y2K38 problem?

If Unix time is stored in a 32-bit signed integer (the original Unix design), it overflows on 19 January 2038 at 03:14:07 UTC. Modern 64-bit systems are unaffected, the overflow date moves to roughly the year 292 billion. The Y2K38 risk is concentrated in 32-bit embedded systems still in deployment (industrial controllers, satellites, automotive infotainment, banking back-ends, IoT sensors with multi-decade lifetimes). Unlike Y2K, the Y2K38 issue won't be a single-day crisis but a series of small failures in long-tail systems over the years approaching 2038.

Does this work offline?

Yes, once the page has loaded, all conversion runs in your browser via JavaScript's built-in Date API. No network calls during use. The "Now" button uses your device's local clock; the live-updating timestamp at the top updates from your system clock without contacting any time server.

Related Tools