About the Timestamp Converter
The Timestamp Converter turns a Unix timestamp into a readable date and time, and a date back into a timestamp. Paste a number like 1767225600 and you see the moment in UTC, in your own time zone and in any other zone you pick, along with how long ago it was.
A Unix timestamp, also called epoch time, counts the seconds since midnight UTC on January 1, 1970. Databases, log files, APIs, JWT tokens and cookies store time this way because one number means the same moment everywhere. That is great for computers and hard for people, which is where this tool helps.
It reads seconds, milliseconds, microseconds and nanoseconds, guesses which one you pasted, handles daylight saving time changes, and converts a whole list at once. The current Unix time ticks at the top of the page. Everything runs in your browser.
How to use it
- Paste a timestampType or paste the number under "Timestamp to date". Auto picks seconds, milliseconds, microseconds or nanoseconds from the number of digits, or you can choose the unit yourself.
- Read the dateYou get the moment in UTC (ISO 8601), in your own time zone, in RFC 2822 format, how long ago or how far ahead it is, and the day of the year with its ISO week.
- Pick another time zoneChoose a zone under "Date to timestamp" and the timestamp result adds a line for that zone with its UTC offset.
- Turn a date into a timestampPick a date and time and a time zone, or type a date such as 2026-10-05T14:30:00Z. You get Unix seconds, milliseconds and the UTC time.
- Convert a listPaste one timestamp per line in "Convert many timestamps" to get each one as a UTC date, ready to copy.
Key features
Seconds to nanoseconds
Up to 11 digits is read as seconds, 12 to 14 as milliseconds, 15 to 17 as microseconds, and 18 or more as nanoseconds. Decimals and negative numbers work too.
Every time zone
All IANA time zones your browser knows, from America/New_York to Asia/Kolkata, with the exact UTC offset for that date, including daylight saving time.
DST-aware in both directions
A local time that does not exist, such as 2:30 AM on the day clocks spring forward, moves to the first valid time. A time that happens twice in the fall uses the first one.
Several formats at once
ISO 8601 for code and APIs, RFC 2822 for email headers and HTTP, a long readable date, and a relative time like "9 months ago".
Batch conversion
Convert a column of timestamps from a log or a database export in one go. Lines that are not numbers are marked as invalid.
Private by design
Nothing is sent to a server. The clock, the conversions and the time zone data all come from your browser.
Examples
Seconds or milliseconds?
The same moment, written three ways. Each one shows 2026-01-01T00:00:00.000Z in UTC, which is Wednesday, December 31, 2025 at 7:00:00 PM EST in New York.
| Timestamp | Digits | Read as |
|---|---|---|
1767225600 | 10 | Seconds |
1767225600000 | 13 | Milliseconds |
1767225600000000 | 16 | Microseconds |
Unix tools, PHP's time() and most databases use seconds. JavaScript's Date.now() and Java's System.currentTimeMillis() use milliseconds. If you force the unit to Milliseconds and paste the 10-digit value, you get 1970-01-21T10:53:45.600Z instead, a classic sign that the units are mixed up.
UTC and local time
A timestamp has no time zone; it is one moment. On Saturday, October 10, 2026 at 2:30 PM in New York, the Unix time is 1791657000. Pick a zone and the converter shows the local time there:
| Zone | Local time | Offset |
|---|---|---|
| UTC | Oct 10, 6:30 PM | UTC+00:00 |
| America/Los_Angeles | Oct 10, 11:30 AM | UTC-07:00 |
| Europe/London | Oct 10, 7:30 PM | UTC+01:00 |
| Asia/Kolkata | Oct 11, 12:00 AM | UTC+05:30 |
| Asia/Tokyo | Oct 11, 3:30 AM | UTC+09:00 |
Going the other way, the time zone matters. Midnight on January 1, 2026 is 1767225600 in UTC but 1767243600 in New York, 18,000 seconds (five hours) later.
Daylight saving time
| New York local time | Timestamp | UTC |
|---|---|---|
| Jul 4, 2026, 12:00 PM | 1783180800 | 16:00 (UTC-04:00) |
| Mar 8, 2026, 2:30 AM (does not exist) | 1772955000 | 07:30, which is 3:30 AM EDT |
| Nov 1, 2026, 1:30 AM (happens twice) | 1793511000 | 05:30, the first 1:30 AM (EDT) |
The year 2038 problem
Older systems store Unix time as a signed 32-bit number, whose largest value is 2147483647. The "2038 limit" button shows that moment: 2038-01-19T03:14:07.000Z, or Monday, January 18, 2038 at 10:14:07 PM EST in New York. One second later, a 32-bit counter wraps around to -2147483648, which the converter shows as 1901-12-13T20:45:52.000Z.
Most current operating systems and languages use 64-bit time and are not affected. The risk is in embedded devices, old file formats, and database columns that still hold 32-bit values; MySQL's TIMESTAMP type, for example, stops at the same second. Unsigned 32-bit fields last longer: 4294967295 is 2106-02-07T06:28:15.000Z.
Round numbers
1000000000 was 2001-09-09T01:46:40.000Z, and 2000000000 will be 2033-05-18T03:33:20.000Z. The "Year 2000" button fills in 946684800, midnight UTC on January 1, 2000, which falls in ISO week 52 of 1999.
Tips
- Count the digits before anything else. Ten digits is seconds for any date between 2001 and 2286, and thirteen digits is milliseconds for the same range.
- Store and send times as UTC timestamps or ISO 8601 with a Z or an offset, and convert to local time only when you show it to a person.
- When you type a date without a zone, the converter reads it in the selected time zone. Add Z or an offset like -04:00 to pin it to an exact moment.
- Check a JWT's exp or iat claim by pasting the number here. The Relative line tells you at a glance whether the token has expired.
- Planning around a 32-bit field? Use the "2038 limit" button to see exactly how much time is left, and test your system with dates past it.
Common mistakes and limits
- Mixing up seconds and millisecondsA millisecond value read as seconds lands tens of thousands of years in the future, and a seconds value read as milliseconds lands in January 1970. If a date looks absurd, check the unit first.
- Thinking a timestamp carries a time zoneIt does not. 1791657000 is the same instant in New York and Tokyo; only the way you display it changes.
- Building a timestamp from local time as if it were UTCTaking 2026-01-01 00:00 New York time and converting it as UTC gives 1767225600, which is five hours too early. Pick the right zone before converting.
- Relying on Auto for millisecond values near 1970Millisecond timestamps from late 1966 to March 3, 1973 have 11 digits or fewer, so Auto reads them as seconds. Choose Milliseconds by hand for those.
- Expecting leap secondsUnix time treats every day as exactly 86,400 seconds and skips leap seconds, so the difference between two timestamps can be up to 27 seconds shorter than the time that really passed since 1972. For everyday use, that never matters.
