Timestamp converter
Enter a Unix timestamp (10-digit seconds or 13-digit milliseconds both work), or pick a date to convert the other way.
10-digit values are read as seconds and 13-digit as milliseconds; values with decimals are treated as milliseconds. Daylight saving and time zones follow the browser's local time zone.
When to use it
- A log line contains only a 10- or 13-digit number and you need the local time and UTC behind it immediately.
- Before writing a timestamp to a database or API, you need to convert ‘2026-10-25 15:30:00’ to Unix seconds and check there is no timezone shift.
When not to
- You are scheduling a meeting across New York, London and Tokyo and need several wall-clock times at once: this page shows only your browser's local zone and UTC, so use a converter with a timezone picker.
- You need to parse an ISO string with an offset (such as 2026-10-25T15:30:00+08:00) or do date arithmetic: this page accepts plain numeric timestamps and local datetime input only.
Everything is converted locally in your browser; input is never uploaded and is not written to the URL or a log. Limits: it accepts plain numeric timestamps (optional minus sign and decimals) or a local datetime, not ISO strings with an offset; the local row follows your browser or OS time zone with no manual switch; relative time stops at seconds, minutes, hours and days, so anything more than a day away is shown in accumulated days rather than months or years.
Frequently asked
How do I tell seconds from milliseconds?
10 digits (1761328800) are seconds; 13 digits (1761328800000) are milliseconds — a factor of 1,000. This tool compares the absolute value with 10^11: below is seconds, at or above is milliseconds, so 12- and 13-digit values are milliseconds while 11 digits still count as seconds. Any input with a decimal point is treated as milliseconds. If unsure, press ‘Current time’ and compare digit counts.
How are time zones handled?
The local-time row uses your browser's time zone (normally the system zone), and daylight saving is applied by the browser according to that zone's rules. The ISO 8601 and UTC rows always use UTC; the ISO output looks like 2026-10-25T07:30:00.000Z. There is no manual timezone switch, so the same timestamp shows a different local time on computers in different zones, while UTC and ISO stay the same.
Does the year 2038 problem affect this tool?
No. The 2038 problem comes from storing Unix seconds in a signed 32-bit integer, which tops out at 2,147,483,647 — 2038-01-19T03:14:07Z — and then overflows. This page uses JavaScript Number and Date (double precision), so it converts dates well past 2038, up to Date's limit of about ±8.64e15 milliseconds (roughly ±275,000 years). Your database or server may still use a 32-bit time column, so check before writing far-future values.