Unix Timestamp Converter

One integer, two units, one epoch

A Unix timestamp is a single integer counting seconds (or milliseconds) since 1 January 1970 00:00:00 UTC. Logs, APIs and databases breathe them, and every conversation with one has exactly one trap: which unit is it? This page takes either — ten digits usually means seconds, thirteen usually means milliseconds — and prints the date in UTC (ISO 8601) and in your device's local time. The default value, 1790899200, reads as 2026-10-02T00:00:00.000Z — midnight UTC on 2 October 2026 — which makes a good origin point for debugging a week of records.

Reading two timestamps in the local panel is the fastest diagnostic in operations: a server log written at 22:13 UTC will show "23:13" in a device set to UTC+1, and the tool's local-time line is exactly the place to see that one-hour offset rather than to suspect a bug.

A worked example, step by step

Scenario: a monitoring dashboard shows a spike starting at timestamp 1750000000 (seconds). What human time is that?

1. Paste 1750000000, keep the unit on seconds.
2. UTC read: 2025-06-15T15:06:40Z — mid-afternoon UTC on 15 June 2025.
3. Local read: your device applies its own offset (interesting exactly when the correlated alert scrolls by).
4. Cross-check: 946684800 in the same panel reads 2000-01-01T00:00:00Z — a timestamp you already know, confirming the unit is right.
5. Trap drill: if a colleague pastes 1790899200000 while the unit says seconds, the panel shows a date tens of thousands of years out; switch to milliseconds and it returns to 2026-10-02.

Both panels live on the same page, so a single paste answers the two halves of every timestamp question: when was it in UTC (for the ticket) and when was it locally (for the memory of who was on shift).

Landmark timestamps worth knowing

Landmarks double as unit checks: any timestamp that produces a date before 2000 while analyzing modern data is almost certainly the wrong unit, not a historical record.

Milliseconds, and the division by 1000

JavaScript's Date and most database drivers switch units at their convenience: JavaScript uses milliseconds natively, PostgreSQL's Bigint timestamps often arrive in seconds, and a JSON export from a mobile app may use either. The simple visual rule: 10 digits is seconds, 13 digits is milliseconds. When in doubt, the tool's radio is the arbiter: paste the same digits under each unit and see which output lands in your expected year. One 2026-10-02-shaped output versus an 18th-century date will settle the argument in seconds — or milliseconds, as the case may be.

Mistakes that quietly shift a timestamp

• Wrong unit, plausible date. A millisecond value read as seconds lands centuries off; a second value read as milliseconds lands 1970-01-01-ish.
• Treating the local line as the UTC one. The two lines differ by your device offset; the ticket should quote the UTC (ISO) read.
• Extrapolating beyond safe range. Far-future values beyond the year range a platform handles fail or wrap; guard inputs at your system's edges.
• Assuming every log uses the same unit. Systems in the same stack disagree; convert between them explicitly instead of eyeballing.
• Copy-trimming trailing zeros. 1790899200.0 is the same instant as 1790899200, but a 17000000000-class paste is a different decade entirely.

Keep exploring

• Days Until a Date — the gap between two dates as a plain countdown.
• Date Difference — span between two full dates, expressed in total days.
• Time Duration Calculator — time-of-day arithmetic, the counterpart to epoch arithmetic.
• Guide: Working with Dates and Time.