Convert a single Unix epoch timestamp between seconds, milliseconds, microseconds, and nanoseconds — and instantly see the matching UTC date-time. Useful when one API gives you milliseconds, another wants seconds, and your tracing system logs nanoseconds.
How it works
Every unit is a power of 1000 apart:
1 s = 1,000 ms = 1,000,000 µs = 1,000,000,000 nsThe tool first normalises your input to nanoseconds (the finest unit), then derives every other unit by integer division. Because nanosecond values are far larger than JavaScript’s safe-integer limit, all conversion uses BigInt so no precision is lost:
ns = value * scaleToNs[unit]
seconds = ns / 1_000_000_000n
milliseconds = ns / 1_000_000n
microseconds = ns / 1_000nFor the human-readable date, the value is reduced to milliseconds and formatted in UTC.
Worked example
A millisecond timestamp 1780000000000:
- Seconds:
1780000000 - Microseconds:
1780000000000000 - Nanoseconds:
1780000000000000000 - UTC date: 2026-05-28 20:26:40 UTC
Which unit is which API using?
The most common point of confusion with epoch timestamps is not the math — it is identifying which unit your source is providing. Here are some typical patterns:
| System | Usual epoch unit | Example value |
|---|---|---|
Unix shell (date +%s) | Seconds | 1780000000 |
JavaScript Date.now() | Milliseconds | 1780000000000 |
Python time.time() | Seconds (float) | 1780000000.123 |
Python time.time_ns() | Nanoseconds | 1780000000123000000 |
Go time.Now().UnixNano() | Nanoseconds | 1780000000123456789 |
PostgreSQL EXTRACT(EPOCH FROM now()) | Seconds (float) | 1780000000.456 |
| AWS CloudTrail, most REST APIs | Milliseconds | 1780000000000 |
| OpenTelemetry traces | Nanoseconds | 1780000000123456789 |
A quick sanity check: a second-resolution timestamp for 2026 is a 10-digit number around 178xxxxxxx; milliseconds is 13 digits; microseconds is 16 digits; nanoseconds is 19 digits. If you paste a value and the UTC date looks nonsensical (year 1970 or year 56000), you likely have the wrong unit selected.
Why BigInt matters for nanoseconds
JavaScript’s Number type uses IEEE-754 double precision, which can represent integers exactly up to 2⁵³ − 1, or about 9 quadrillion. A nanosecond timestamp for the year 2026 is around 1.78 × 10¹⁸, well within that range — but only barely. By 2262, nanosecond timestamps will exceed the safe integer limit and Number arithmetic will silently lose precision in the last few digits. The tool uses BigInt throughout so conversions are exact for any valid timestamp, regardless of era.
Notes
Inputs must be whole integers — epoch values do not contain fractional units in these systems. If your source gives you a float (such as Python’s time.time()), truncate or round before entering. Negative values are valid and represent dates before 1 January 1970 UTC. All math runs locally in your browser — nothing is uploaded.