Unix Timestamp Converter
Convert a Unix timestamp (seconds or milliseconds) to a human-readable date, or pick a date and time to get its Unix timestamp — with ISO 8601, UTC, local, and relative output.
Interactive Client Prototype Sandbox
Disclaimer: This free tool is provided “as is,” without warranties of any kind, and is for general informational purposes only — not professional, legal, financial, medical, tax, or engineering advice. Results may contain errors; verify anything important independently and use at your own risk. We accept no liability for any loss or damage arising from its use. See our Terms of Use for details.
Step-by-Step Guide
Choose whether you're working in seconds or milliseconds using the unit toggle — most Unix timestamps from Linux, Python, and SQL are in seconds, while JavaScript's Date.now() and many JSON APIs use milliseconds. Type a timestamp into the left field to see it converted to ISO 8601, UTC, your local time, and a plain-English relative description ('2 days ago', 'in 3 hours').
To go the other direction, use the date-and-time picker on the right: pick any date and time in your local timezone and the Unix seconds and milliseconds update immediately. Click 'Now' to load the current timestamp, or 'Example' to load a fixed reference date.
Seconds vs. milliseconds
If a timestamp looks like 1704067200 (10 digits), it's almost certainly in seconds. If it looks like 1704067200000 (13 digits), it's in milliseconds. Feeding a millisecond value into a tool expecting seconds — or vice versa — produces a date wildly in the past (1970) or an invalid future date, which is the most common mistake when working with epoch time.
Timestamp 1704067200 (seconds) converts to 2024-01-01T00:00:00.000Z in ISO 8601, 'Mon, 01 Jan 2024 00:00:00 GMT' in UTC, and a relative time based on today's date. Entering January 1, 2024 at midnight in the date picker produces the same 1704067200 back in the seconds field.
Who it's for
Backend developers, DevOps engineers, QA testers, and anyone debugging logs, API responses, or database rows that store epoch time.
Core Features
- Convert a Unix timestamp in seconds or milliseconds to a full date breakdown.
- Convert any date and time back to Unix seconds and milliseconds.
- Shows ISO 8601, UTC string, local time, and a human relative time ('3 hours ago') together.
- One-click 'Now' button and copy buttons on every output row.
- Runs entirely in your browser using your device's own clock and timezone.
🛡️ No tracking — your inputs, keys, and details never leave this client sandbox.
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 January 1, 1970 (the Unix epoch), not counting leap seconds. It's a compact, timezone-independent way to store a single instant in time, which is why it's the default in Linux systems, most databases, and many APIs.
Why do some timestamps have 10 digits and others 13?
A 10-digit number is Unix time in seconds; a 13-digit number is Unix time in milliseconds (seconds × 1000). JavaScript's Date.now() and Date.prototype.getTime() return milliseconds, while most Unix/Linux tools, Python's time.time(), and many SQL epoch columns use seconds. Always check which unit an API or database documents before converting.
Does this tool account for my timezone?
A Unix timestamp itself has no timezone — it's always relative to UTC. This tool converts it to your device's local timezone for the 'Local time' output using your browser's own timezone setting, while also showing the UTC value so you can compare the two directly.
What happens to Unix time after the year 2038?
Systems that store Unix time as a signed 32-bit integer will overflow at 03:14:07 UTC on January 19, 2038 (the 'Year 2038 problem'), wrapping to a negative number. Modern systems increasingly use 64-bit integers for epoch time, which pushes the overflow far into the future. This tool uses JavaScript's native Date object, which is unaffected by the 32-bit limit.
Is my timestamp or date sent to a server?
No. The conversion uses only your browser's built-in Date object and your device's clock and timezone setting — nothing is transmitted anywhere.
Why software stores time as a number
Storing a moment in time as a single integer — seconds since a fixed reference point — sidesteps almost every problem that comes with storing a formatted date string. There's no ambiguity between MM/DD/YYYY and DD/MM/YYYY, no timezone to misinterpret, and no locale-specific month name to parse. Sorting, comparing, and doing arithmetic on two timestamps is just integer subtraction. This is why Unix time, standardized around the Unix epoch of January 1, 1970, became the near-universal internal representation across operating systems, databases, and APIs, even though virtually no human thinks in epoch seconds.
Where epoch time shows up in practice
A developer runs into raw Unix timestamps constantly: a `created_at` column stored as a BIGINT in Postgres or MySQL, a JWT's `exp` and `iat` claims, a log line from a load balancer, a cron job's last-run marker, or a webhook payload from a third-party API. Because the raw number is unreadable, converting it back and forth is one of the most repeated micro-tasks in backend and DevOps work — usually as an interruption in the middle of debugging something else, which is exactly when a fast, no-friction tool matters most.
Common pitfalls
The single most frequent bug is a unit mismatch: passing a millisecond value to code that expects seconds produces a date around 1970 (since the number, read as seconds, represents only a few minutes past the epoch), while passing seconds to code expecting milliseconds produces a date far in the past relative to what was intended. A second common issue is timezone confusion — a Unix timestamp is unambiguous, but the moment it's rendered as a local date string, the reader needs to know which timezone was used to render it, and 'today' can mean a different calendar date in Tokyo than in Los Angeles for the same instant.