Unix Timestamp Converter
Convert a Unix timestamp (epoch) into a readable date, or a date into its timestamp, right in your browser.
—Timestamp to date
Enter a timestamp to convert it to a date.
Date to timestamp
Pick a date and time to convert it to a timestamp.
What a Unix timestamp is, and how this converter works
A Unix timestamp (or "epoch time") is the number of seconds elapsed since midnight UTC on January 1st, 1970 — the reference point (the "epoch") Unix systems chose. It's the most common way to represent a point in time in software because it's a single number, independent of language, format, or time zone: easy to store in a database column, compare, sort, and exchange between different systems without ambiguity. This tool converts in both directions — timestamp to readable date, and date to timestamp — entirely in your browser.
A "raw" Unix timestamp is in seconds, but plenty of languages and APIs (JavaScript included: Date.now() returns milliseconds) work in milliseconds instead. This tool auto-detects the unit from the digit count: up to 10 digits is read as seconds, 11 to 13 as milliseconds. Mixing up the two units is a common, sneaky bug: misreading a seconds value as milliseconds produces a date right next to the epoch itself (January 1970), while the opposite mistake throws the date thousands of years into the future.
The timestamp itself carries no time zone — it's an absolute count of seconds, identical everywhere in the world at the same instant. Time zone only enters the picture when converting it into a human-readable date: "10:00" means something different in Rome, London, or New York at the exact same moment. To avoid the classic "off by a few hours" mix-up, this tool always shows both UTC and your browser's local time side by side.
Unix timestamps show up everywhere in software development: in a JWT's iat (issued at), exp (expiration), and nbf (not before) claims, in a database's created_at or updated_at columns, in HTTP cache headers like Expires, or in application logs. Pasting the value you found in an API response or a decoded token here is the fastest way to see exactly what real instant it corresponds to, without doing the math by hand.
A real technical curiosity: systems that store a Unix timestamp as a signed 32-bit integer will overflow on January 19, 2038 at 03:14:07 UTC (the so-called "Year 2038 problem," the Unix-epoch equivalent of the Millennium Bug), because that's the largest value the format can represent before the count wraps around to negative. Modern systems use 64-bit integers and aren't affected, but legacy software vulnerable to it still turns up. A timestamp can also be negative, representing dates before 1970 — this tool handles those correctly.
Frequently asked questions
- Is the data I enter sent to a server?
- No. All conversion happens in your browser using the native Date and Intl APIs. No value is ever transmitted or stored.
- How does the tool know if a number is in seconds or milliseconds?
- By digit count: up to 10 digits is read as seconds (covering dates up to the year 2286), 11 to 13 digits as milliseconds. It's the same convention most equivalent tools use, since in practice the two formats are never ambiguous.
- Why is the time shown different from what I expected?
- You're probably comparing UTC with local time: a Unix timestamp has no time zone of its own, so the tool always shows both side by side to avoid the classic few-hours mix-up.
- What is the Year 2038 problem?
- Systems that store a Unix timestamp as a signed 32-bit integer overflow on January 19, 2038 at 03:14:07 UTC, wrapping around to a negative value. It only affects legacy software — modern 64-bit systems don't have this limit.
From the books
