Timestamp Converter
Convert between Unix timestamps and human-readable dates.
Current Timestamp
Seconds
-
Milliseconds
-
Timestamp to Date
ISO
UTC
Local
Date to Timestamp
Seconds
Milliseconds
Convert between Unix timestamps and human-readable dates.
-
-
A Unix timestamp is an anonymous-looking integer until you convert it. This tool translates timestamps into human-readable dates and back, showing ISO 8601, UTC, and your local time side by side. It is useful for reading server logs, checking API payloads, and inspecting database rows.
The timestamp-to-date direction multiplies by 1000 for seconds or uses the value as-is for milliseconds, then renders the resulting instant three ways. The date-to-timestamp direction does the reverse: it takes a calendar date and optional time from the pickers, interprets them in your browser’s local timezone, and reports the epoch value in both seconds and milliseconds. The seconds result is floored, so a time with fractional seconds is truncated toward the past.
A live panel also shows the current instant in both units, refreshed once per second, so you can copy “now” without reaching for a console.
| Input | Unit | UTC output |
|---|---|---|
| 0 | seconds | 1970-01-01T00:00:00.000Z |
| 1700000000 | seconds | 2023-11-14T22:13:20.000Z |
| 1754478800 | seconds | 2025-08-06T11:13:20.000Z |
| 1754478800000 | milliseconds | 2025-08-06T11:13:20.000Z |
| 2147483647 | seconds | 2038-01-19T03:14:07.000Z |
Going the other way, 1970-01-01T00:00:00Z maps to 0 seconds, and 2024-01-01T00:00:00Z maps to 1704067200 seconds. Those reverse examples are given in UTC; entered through the date picker they reflect the browser’s local offset instead, which is why the same calendar date can yield a number that differs by the size of your timezone offset.
In 2025 a second-based timestamp has 10 digits, around 1.7 billion. A millisecond timestamp has 13 digits, around 1.7 trillion, because JavaScript’s Date.now() counts milliseconds. Some systems go finer still: microseconds are 16 digits and nanoseconds 19. When you paste a value, count the digits before choosing the unit. Passing a 13-digit millisecond value while the selector reads seconds produces a date far in the future, and passing a 10-digit seconds value as milliseconds lands you in January 1970.
The tool does not auto-detect the unit; you must select it. Auto-detection would be a guess, and a wrong guess is harder to notice than an explicit choice.
A timestamp records an instant, not a wall-clock reading, so the number itself is timezone-independent. Only the rendered output changes with location. The ISO output always ends in Z and is therefore stable everywhere. The local output uses the browser’s locale and offset, including daylight saving at that instant, which is exactly what you want when matching a log line to your own clock.
The reverse direction is the trap. Typing a date and time without an offset means “this wall-clock time where I am.” If you meant UTC, enter the timestamp directly or convert the intended UTC date using a UTC-known reference. This is the single most common source of off-by-hours bugs when copying values between machines.
Many older systems store timestamps in a signed 32-bit integer, whose maximum is 2,147,483,647 seconds: 2038-01-19T03:14:07Z. One second later the value wraps negative and is interpreted as December 1901. Modern 64-bit platforms are not affected for any realistic horizon. If you maintain a legacy database or embedded system, this is the date to plan around.
Server logs often print epoch seconds in brackets, such as [1754478800] GET /api/v1/users. Paste the number with the seconds unit selected and the ISO output gives you the exact instant. API error payloads sometimes carry milliseconds instead, recognizable by the 13-digit length; switching the unit fixes the otherwise wrong date.
JWTs are another common source. The iat, nbf, and exp claims are seconds since the epoch. Decoding a token gives you these numbers, and this tool turns an exp claim into an expiry date you can compare against the live current-time panel. A token that expired an hour ago is obvious once the number becomes a date.
Database rows are a third case. Many engines store seconds while JavaScript-based services store milliseconds, so check the column definition or the ORM before choosing the unit. When two systems disagree about a timestamp, compare the epoch integers directly rather than the rendered local strings.
Mixing up seconds and milliseconds is the most frequent error. Next is ignoring the local-time interpretation of the date picker and expecting UTC. A third is comparing timestamps across timezones by eye: compare the epoch numbers, not the rendered local strings. Finally, remember that epoch time ignores leap seconds, so arithmetic on timestamps is not a perfect measure of physical elapsed time.
A subtler mistake is assuming a timestamp carries a timezone. It does not: 1700000000 is the same instant everywhere, and only its display changes. Storing a local wall-clock string instead of an epoch loses the offset and becomes ambiguous twice a year in regions with daylight saving. When in doubt, store the epoch and render on read.
When you enter a date and time, the tool builds a Date in your browser's local timezone and then converts it. A colleague in a different timezone entering the same wall-clock date gets a different epoch number, because the same local time corresponds to a different instant. Enter a timestamp first if you need one unambiguous value.
The conversion relies on JavaScript millisecond arithmetic, which stays exact up to about 8.64 quadrillion milliseconds, roughly the year 275760 in either direction. Timestamps in seconds remain safe for any practical modern date.
Yes. Enter a negative number of seconds or milliseconds and the tool renders the corresponding date before the epoch, for example -86400 converts to 1969-12-31 in UTC.
ISO is the machine-friendly format ending in Z, such as 2025-08-06T11:13:20.000Z. UTC is the same instant in RFC 1123 wording. Local is how that instant reads on your own clock, including your timezone offset.
Seconds and milliseconds differ by a factor of 1000. A value around 1.75 billion is seconds; around 1.75 trillion is milliseconds. If you select the wrong unit, the tool shows a date roughly 1000 times too far in the future or past.
Both are displayed and both update once per second. The seconds field is the familiar 10-digit value and the milliseconds field is the 13-digit value; use whichever the API you are debugging expects.
Reviewed by the HandyTools Hub team · Last updated