Timestamp / Unix Epoch Converter
Converts between Unix timestamps (epoch) and readable date/time, both ways, in real time.
What is a Unix Timestamp
A Unix Timestamp (or epoch) is the count of seconds — or milliseconds — elapsed since a fixed reference instant, independent of time zone, calendar or language: just an integer. It's the most common way to represent date and time in systems, because it's compact, easy to compare (a larger value is always a later instant), and free of ambiguity.
Why January 1st, 1970 as the reference
The reference instant (00:00:00 UTC on January 1st, 1970) is known as the "Unix Epoch". The choice carries no special meaning beyond coinciding with when Unix development started, in the late 1960s — it just needed a fixed starting point close enough to the era, without wasting digits on years no real system would ever need to represent.
Seconds vs. milliseconds
There's no single standard: APIs and databases have historically used seconds (10 digits until the year 2286), while JavaScript, many modern web APIs, and logging systems tend to use milliseconds (13 digits over the same period) — the browser's own Date works internally in milliseconds. This tool detects the unit automatically from the number of digits typed.
What is UTC
UTC (Coordinated Universal Time) is the world's reference time standard, with no time zone offset and no daylight saving — the base from which every local time zone is defined as an offset (e.g., UTC-3 for Brasília time). A Unix timestamp already represents an absolute instant by nature; UTC is just the neutral way to display that instant as readable date/time.
When to use UTC and when to convert to local time
Use UTC for storage, logging, and exchanging data between systems — it removes time zone ambiguity and prevents bugs when server and user are in different zones. Only convert to local time at the presentation layer, right when the value is shown directly to a person.
Where you'll find a Unix Timestamp
In the responses of practically every REST API (creation/update dates), in the date columns of relational and non-relational databases, in every line of a log file, and in the iat/exp/nbf claims of a JWT (see JWT Decode) — always in seconds, per RFC 7519 convention.
Frequently asked questions
Yes — it represents an instant before January 1st, 1970. This tool accepts and converts it normally, in both directions.
By the digit count: up to 10 digits is almost always seconds (until roughly the year 2286); 11 or more is almost always milliseconds. There's no absolute guarantee, but that's the convention followed by most tools and libraries, including this one.
No. The count assumes every day has exactly 86,400 seconds, ignoring the leap seconds periodically inserted to keep civil time aligned with Earth's rotation — so it isn't suited for very high-precision astronomical calculations.
Systems that store the timestamp in a signed 32-bit integer (still common in legacy software) overflow on January 19th, 2038 at 03:14:07 UTC — the so-called "Year 2038 problem", analogous to the Y2K bug. Modern systems, using 64-bit integers, have no such limit in practice.