Unix Timestamp Converter at a glance
- What it does
- Convert Unix epoch timestamps to human-readable dates and back, in seconds or milliseconds, with UTC and local time shown side by side.
- Where it runs
- Entirely in your browser — no data is uploaded
- Works offline
- Yes, once the page has loaded
- Cost
- Free, with no account and no usage limit
- Category
- Converters
How to use the converter
- Paste a timestamp to see the date in both UTC and your local timezone.
- Or pick a date and time to get the corresponding epoch value.
- Check the units. Ten digits is seconds, thirteen is milliseconds - the most common mistake in this conversion.
Seconds or milliseconds
The Unix convention is seconds, and that is what most backend languages, databases and APIs use. JavaScript is the significant exception: Date.now() returns milliseconds.
Mixing them produces a distinctive bug. A seconds value read as milliseconds lands in January 1970; a milliseconds value read as seconds lands somewhere around the year 55,000. If a date is wildly wrong in one of those two directions, this is the reason.
| Digits | Unit | Example |
|---|---|---|
| 10 | Seconds | 1789430400 |
| 13 | Milliseconds | 1789430400000 |
| 16 | Microseconds | Common in Python and some databases |
| 19 | Nanoseconds | Go, and high-resolution monitoring systems |
Why 1970
The choice was practical rather than principled. Unix was being developed at Bell Labs around 1970, and the earliest implementations counted sixtieths of a second in a 32-bit integer - which overflowed in about two and a half years. Moving to whole seconds with an epoch at the start of 1970 gave a comfortable margin with the hardware of the time.
Other systems chose differently: Windows file times count 100-nanosecond intervals since 1601, and older Mac software used 1904. When a date appears as 1601 or 1904 rather than 1970, you are looking at a zero value in one of those systems.
The 2038 problem
A signed 32-bit integer holding seconds overflows on 19 January 2038, at which point the value wraps to a negative number and the date becomes December 1901. Any system still using a 32-bit time_t will get this wrong.
Modern 64-bit systems are unaffected, and a 64-bit counter lasts around 292 billion years. The real risk sits in embedded devices, industrial controllers and long-lived file formats - equipment installed today with a twenty-year service life that nobody will think to check. Systems calculating far-future dates, such as thirty-year mortgages, can hit it well before 2038.
Storing time without regretting it
- Store UTC, display local. Convert at the edge, at the moment you render. Storing local time loses the offset and cannot be recovered.
- Use ISO 8601 for interchange.
2026-09-09T14:30:00Zis unambiguous, sorts correctly as a string and is readable. JSON has no date type, so this is the convention. - Store a timezone name for future events. A meeting scheduled for "9am in London next March" cannot be stored as a UTC instant, because a government could change the daylight-saving rules before then. Store the local time plus
Europe/London. - Never store a raw offset like +05:30 as a substitute for a timezone. Offsets change twice a year in most of the world.
- Beware leap seconds. Unix time ignores them by convention, so it is not a true count of elapsed SI seconds. This matters only for high-precision work, but it does matter there.
Frequently asked questions
Always. The epoch is defined at midnight UTC, and a timestamp carries no timezone information. Any local time you see is produced by converting it for display.
Almost certainly a zero or null timestamp, or a milliseconds value being interpreted as seconds. 1 January 1970 is what a zero renders as.
new Date(ts * 1000) if your value is in seconds, because the JavaScript Date constructor expects milliseconds. Omitting the multiplication is a very common bug.
No. Unix time treats every day as exactly 86,400 seconds and simply repeats or skips a value when a leap second occurs. It is a count of days-times-86400, not of elapsed physical seconds.
For a signed 32-bit integer, 2,147,483,647 - which falls on 19 January 2038. 64-bit systems have no practical limit.
Nothing you enter here leaves your browser
Unix Timestamp Converter does its work in JavaScript running on your own device. The page loads once, and after that there is no upload step and no server involved — which matters here because exported data frequently contains customer records or transactions.
You can verify this rather than taking our word for it: load the page, disconnect from the internet, and the tool keeps working. Our privacy policy sets out what is and is not collected, and this guide explains why the distinction matters.