Convert Unix timestamps and dates
Paste epoch numbers or date strings, one per line, and get every representation back: Unix seconds, milliseconds, ISO 8601, UTC, your local time and a plain-English relative time. The unit is detected from the number of digits, or you can force it. Leave the box empty and press Convert to see the current time.
How to use the Unix Timestamp Converter
- Paste timestamps or dates, one per line (up to 200).
- Numbers are read as Unix time; anything else is parsed as a date string.
- Read the table for UTC, local and relative values.
- Leave the box empty and press Convert for the current timestamp.
What Unix time is
Unix time counts the seconds elapsed since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. It is a single integer with no time zone attached, which is exactly why it is the right thing to store in a database and to send between services: there is no ambiguity about which offset was meant, and arithmetic is trivial. Humans then format it in whatever zone they happen to be in.
Seconds, milliseconds, microseconds
The unit is the single most common source of bugs, because the same instant is written three different ways. As a rule of thumb, a present-day timestamp has 10 digits in seconds, 13 in milliseconds and 16 in microseconds — which is how auto-detection works here.
| Unit | Now looks like | Typical source |
|---|---|---|
| Seconds | 1758585600 (10 digits) | Unix tools, PHP time(), JWT exp, Postgres epoch |
| Milliseconds | 1758585600000 (13 digits) | JavaScript Date.now(), Java, Kafka |
| Microseconds | 1758585600000000 (16 digits) | Python time_ns()/1000, some tracing systems |
Reading dates the other way
Any line that is not a plain number is parsed as a date. ISO 8601 is the format to prefer: 2026-09-23T14:30:00Z is unambiguous, sorts correctly as text, and is understood everywhere. Be careful with bare formats — 2026-09-23 without a time is treated as midnight UTC, while 23/09/2026 is read differently in British and American conventions, and a date-time with no offset is assumed to be local. If a result is a day out, a missing Z is usually why.
Time zones and daylight saving
Local times here use your browser zone, shown beneath the table, including the correct daylight-saving offset for that particular date rather than today's offset. This matters when converting timestamps from the summer while it is winter. UTC never shifts, which is another reason to store it and convert only for display.
Limits worth knowing
A signed 32-bit seconds counter overflows on 19 January 2038, which still affects older embedded systems, some MySQL TIMESTAMP columns and legacy C code; 64-bit storage solves it. JavaScript dates themselves are limited to ±8.64 × 1015 milliseconds, roughly ±273,790 years around 1970, and this tool reports anything beyond that rather than showing a wrong date. Negative timestamps are valid and represent dates before 1970.
Frequently asked questions
How do I tell seconds from milliseconds?
Count the digits: a current timestamp is 10 digits in seconds and 13 in milliseconds. Auto-detect uses that rule, and you can override it.
Why is my date one day out?
Almost always a missing time zone. A date with no offset is read as local time, and a bare ISO date is read as midnight UTC.
Does it handle dates before 1970?
Yes. Negative timestamps are valid and convert normally.
What is the year 2038 problem?
Systems storing Unix time in a signed 32-bit integer overflow on 19 January 2038. Anything using 64-bit storage, including modern databases and JavaScript, is unaffected.
Privacy
This tool runs entirely inside your browser using WebAssembly and the Canvas/File APIs. Your files are never uploaded to ToolFlint or any third party; you can verify this in your browser's network tab or by switching to airplane mode after the page loads. Read how we process files.
Last updated 2026-09-23.