Epoch and Unix timestamp converter
Convert Unix timestamps to and from readable dates. The tool detects seconds or milliseconds by itself, and shows ISO 8601, RFC 2822, relative time and seven common time zones. Everything runs in your browser.
Pick a date and time; it is read in your local time zone.
Result
Enter an epoch or date above.What is Unix epoch time?
Unix time, also called epoch time or POSIX time, is the number of seconds that have passed since 1970-01-01T00:00:00Z (the "Unix epoch"). It is the most common way computers exchange a point in time: a single integer, with no time zone, easy to compare and easy to subtract.
Systems that need more precision use milliseconds, microseconds or nanoseconds since the same epoch. JavaScript's Date.now() returns milliseconds; most server-side APIs return seconds. Knowing which one you have is the difference between "right now" and "the year 50,000".
When to use this tool
- Reading log lines. Server logs often use epoch seconds because it is the cheapest format to write. Paste one here to get the readable date back.
- Checking a JWT
expclaim. The expiry claim is an integer epoch. A decoded payload shows"exp": 1760000000; this tool tells you that is 2025-10-09 in your local time zone. - Picking a deadline for a refresh token. Adding 30 days to "now" is easier with epoch numbers than with strings. Take "now" from above and add
30 * 24 * 3600. - Comparing timestamps across services. If service A reports
1700000000and service B reports1700000000000, they are the same moment: one is seconds, the other is milliseconds. The unit badge tells you which is which.
How epoch time works
Pick a reference moment ("the epoch") and count whole ticks since then. Unix picked 1970-01-01 UTC because the system was new and the date was round. Other epochs exist: NTP uses 1900, Windows FILETIME uses 1601, Apple uses 2001. They are all just offsets.
A 32-bit signed integer can count up to 2,147,483,647 seconds, which is 2038-01-19 03:14:07Z. After that it wraps to a large negative number. This is the "Year 2038 problem". Linux moved to a 64-bit time_t years ago; this matters mostly to embedded systems and old binary file formats.
Worked examples
1516239022is 10 digits, so seconds: 2018-01-18T01:30:22Z. This is the well-known timestamp used in the JWT.io demo token.1700000000000is 13 digits, so milliseconds: 2023-11-14T22:13:20Z.-1is one second before the epoch: 1969-12-31T23:59:59Z. Negative timestamps are allowed in Unix time but rare.2147483647is the last second a signed 32-bit timestamp can hold: 2038-01-19T03:14:07Z.
Common mistakes
- Seconds against milliseconds. Most bugs between languages here are unit mismatches. If a date looks 1000 years in the future or 50 years in the past, your unit is off by 1000.
- Local time against UTC. In JavaScript,
new Date("2024-01-01")is read as UTC, butnew Date("2024-01-01 00:00")(with a space) is read as local time. Always send ISO 8601 with an explicit zone to avoid surprises. - Daylight saving. Adding "24 hours" to a local time can land you on the wrong day twice a year. Adding 86400 seconds to a Unix timestamp does not have that problem, because the timestamp has no zone.
- The 2038 problem. It still hits embedded devices, old C structs and some database column types (MySQL
TIMESTAMPis 32-bit). For new schemas, useBIGINTfor epoch values or a native date and time type. - Leap seconds. Unix time ignores them, so the same Unix timestamp can name two different real moments when one is inserted. This almost never matters; for GPS or astronomy work, look up TAI.
FAQ
What is a Unix timestamp?
A Unix timestamp is the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z. It is the most common way computers store and exchange a point in time.
Why does my timestamp show the wrong time?
Most likely a seconds and milliseconds mix-up. A 13-digit timestamp is milliseconds; a 10-digit one is seconds. This tool detects the unit by itself, but other code may not.
What is the 2038 problem?
A signed 32-bit integer overflows at 2038-01-19 03:14:07Z. Systems still using a 32-bit time_t will wrap to a negative number. Modern systems use a 64-bit time_t and are safe.
What is the difference between UTC and GMT?
For most purposes they are the same. GMT is a time zone; UTC is a time standard. Servers and APIs always use UTC.
Do leap seconds break Unix timestamps?
Unix time ignores leap seconds: a Unix timestamp can repeat or skip a second when one is inserted. For most applications you never notice; systems that need exact time use TAI or similar.