Unix Timestamp Converter
Convert Unix epoch timestamps to readable UTC and local dates — and back — in seconds or milliseconds, with a live clock. Updates as you type, completely free, and entirely in your browser.
Timestamp → date
Date → timestamp
Interpreted in your local time zone, matching how the picker displays.
What this tool does, and the traps to avoid
A Unix timestamp is just an integer: the number of seconds since the start of 1 January 1970 UTC. That simplicity is its strength — it pins down an exact instant with no time-zone ambiguity, which is why logs, databases, JWTs, and APIs lean on it. This tool converts that integer into readable UTC and local datetimes and back again, recalculating the moment you type.
The seconds-versus-milliseconds mismatch is the bug we see most often. The Unix convention is seconds; JavaScript's Date and many web APIs use milliseconds — a 1000× difference. Feed seconds into a millisecond parser and your date lands in 1970; do the reverse and it rockets tens of thousands of years into the future. A current seconds value is ~10 digits and a milliseconds value is ~13, so the digit count is a fast sanity check. Here you choose the unit explicitly, so there is nothing to guess.
The other recurring mistake is mixing up UTC and local time. The instant never changes — only how it is displayed. The discipline that prevents an entire category of scheduling and reporting bugs is simple: store in UTC, display in local. Keep raw epoch integers or UTC in your database and logs, and apply the viewer's time zone only at the final render step. We architect data layers around exactly this principle — see our custom business software work.
Everything runs locally with the native Date object — no requests, nothing stored — so you can safely paste timestamps lifted straight from production logs or token payloads. The live clock at the top simply reads your system time, which is handy for grabbing “now” in either unit with one click.
How to use it
To go from a timestamp to a date, choose Seconds or Millis, then type or paste your epoch value — you will get the UTC ISO string, a readable UTC time, your local time, and a relative “x ago / in x” hint. Press “Use now” to drop in the current timestamp. To go the other way, pick a date and time in the picker (interpreted in your local zone) and copy out the matching seconds or milliseconds. Nothing is stored, so a refresh clears everything.
FAQs
What is a Unix timestamp?
A Unix timestamp, also called epoch time, is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It is a single integer that represents an exact instant independent of time zone, which is why systems use it for logs, databases, tokens, and APIs. Because it is just a count from a fixed origin, the same timestamp means the same moment everywhere on Earth — the time zone only matters when you format it for a human.
Seconds or milliseconds — how do I tell them apart?
It is the single most common timestamp bug. Unix tools and most backends use seconds, while JavaScript's Date and many web APIs use milliseconds — a factor of 1000 difference. A quick sanity check: a current seconds-based timestamp is about 10 digits, while a milliseconds one is about 13 digits. If a date comes out in 1970 you almost certainly fed milliseconds into a seconds parser; if it lands tens of thousands of years in the future, you did the reverse. This tool lets you pick the unit explicitly so there is no guessing.
Why do UTC and local time differ here?
The underlying instant is identical; only the presentation changes. UTC is the universal reference with no offset, and it is what you should store and transmit. Local time applies your machine's time-zone offset and daylight-saving rules so the value reads naturally to you. The golden rule for software is store in UTC, display in local: keep every timestamp as UTC (or a raw epoch integer) in your database and logs, and convert to the user's zone only at the very edge when you render it.
Is my data sent anywhere?
No. Every conversion uses the browser's native Date object and runs entirely on your machine — there are no network requests, and nothing is logged or stored. The live current-time display simply reads your system clock. You can confirm the absence of traffic in your browser's network tab. That makes it safe to paste timestamps pulled from production logs or access tokens without exposing them to a third party.
What about the year 2038 problem?
Systems that store Unix time in a signed 32-bit integer overflow on 19 January 2038, when the second count exceeds 2,147,483,647 and wraps to a negative number. The fix is to use 64-bit timestamps, which most modern languages and databases already do. This tool uses JavaScript numbers, which represent the millisecond value as a double and comfortably cover dates far beyond 2038 — though extremely distant dates eventually hit the engine's safe-integer limits, at which point precision degrades.
Related tools
Related engineering reading
All postsAdding AI Features to Your SaaS (2026)
Where AI helps, build-vs-API trade-offs, evals, guardrails, and shipping without torching margins.
Read postAPI Rate Limiting Strategies for 2026
Token bucket vs sliding window, per-key quotas, 429 semantics, and where to enforce limits.
Read postAPI Security Best Practices (2026)
Auth, rate limiting, input validation, secrets, and the OWASP API Top 10.
Read post
Time-zone bugs eating your reports?
Off-by-one days, double-counted hours after daylight saving, and seconds-versus-milliseconds slips come from data layers that were never designed for time correctly. We build systems that store in UTC and render in local, so your timestamps stay trustworthy. Talk to us about a build or an audit.
Or reach us directly: beltz@quantlabusa.dev