What is the Timestamp Converter?
This tool converts between Unix timestamps and human-readable dates in both directions, showing the result in UTC and your local timezone so you can check what a numeric timestamp in a log or database actually represents.
A Unix timestamp counts the seconds elapsed since midnight UTC on 1 January 1970. Because it is a single integer with no timezone attached, it is unambiguous, the same instant everywhere, which is why it is so widely used for storage and transmission.
The trade-off is that it is unreadable. 1700000000 conveys nothing to a human, so converting it is a routine part of reading logs, inspecting database rows, and debugging token expiry.
The most frequent source of confusion is units. Unix timestamps are traditionally in seconds, but JavaScript's Date.now and many APIs use milliseconds. A value interpreted with the wrong unit lands roughly fifty years away from the intended date, which is usually obvious once you see the converted result.
How to use the Timestamp Converter
- Paste a timestamp. Enter a Unix timestamp in seconds or milliseconds; the tool infers the unit from the magnitude.
- Read the converted date. The result is shown in UTC and in your local timezone, along with the ISO 8601 representation.
- Or convert in reverse. Enter a date and time to get the corresponding timestamp.
- Use the current time. The live current timestamp is displayed, which is handy for setting expiry values.
Worked examples
Converting a timestamp
The same instant expressed several ways. ISO 8601 is generally the best format for interchange because it is unambiguous and sorts lexicographically.
1700000000UTC: Tue, 14 Nov 2023 22:13:20 GMT
ISO: 2023-11-14T22:13:20.000Z
Local: depends on your timezone offsetSeconds versus milliseconds
Getting the unit wrong is the classic timestamp bug, and the error is large enough to spot immediately.
1700000000 (10 digits, seconds)
1700000000000 (13 digits, milliseconds)As seconds: 14 Nov 2023
As milliseconds: 20 Jan 1970
A 10-digit value is seconds; 13 digits is
milliseconds. Interpreting one as the other
puts you decades off.Common use cases
- Reading application logs. Log entries frequently carry numeric timestamps that must be converted to correlate with a reported incident time.
- Debugging token expiry. JWT exp and iat claims are Unix timestamps; converting them shows whether a token is actually expired.
- Inspecting database records. Columns storing epoch integers need conversion to be interpretable.
- Setting expiry values. Computing a timestamp for a future moment is often needed when configuring caches or tokens.
Features and limitations
- Converts in both directions between timestamps and dates.
- Automatically detects whether a value is in seconds or milliseconds based on its magnitude.
- Shows UTC, local time, and ISO 8601 simultaneously.
- Displays a live current timestamp.
- Local time uses your browser's timezone, which reflects your system clock and locale settings.
Frequently asked questions
What is a Unix timestamp?
The number of seconds since 1 January 1970 at midnight UTC, known as the Unix epoch. It represents an absolute instant with no timezone attached.
How do I tell seconds from milliseconds?
Count the digits. Contemporary timestamps in seconds have 10 digits; in milliseconds they have 13. If a converted date lands in 1970, you have almost certainly passed milliseconds where seconds were expected.
Why does the local time differ from UTC?
Local time applies your timezone offset, including daylight saving where it is in effect. Both represent the same instant, expressed against different reference points.
What is the year 2038 problem?
Systems storing timestamps as signed 32-bit integers overflow on 19 January 2038. Modern systems use 64-bit values, which pushes the limit far beyond any practical horizon, but legacy systems remain affected.
Do timestamps account for leap seconds?
No. Unix time deliberately ignores leap seconds, treating every day as exactly 86,400 seconds. This keeps arithmetic simple at the cost of a small divergence from astronomical time.
Which format should I use for APIs?
ISO 8601 with an explicit offset, such as 2023-11-14T22:13:20Z, is generally preferable for interchange because it is human-readable and unambiguous. Numeric timestamps remain convenient for internal storage and arithmetic.
All processing happens locally in your browser, your data never leaves your device.