Unix Timestamp Converter

This free unix timestamp converter works in both directions: paste an epoch timestamp to see the human-readable date in UTC and your local timezone, or pick a date and time to get its Unix timestamp. It auto-detects seconds vs. milliseconds, and a one-click button grabs the current timestamp.

How to Use the Unix Timestamp Converter

Working timestamp → date: paste any epoch value into the first field — 10 digits for seconds or 13 digits for milliseconds — and the result appears instantly. The tool tells you which unit it detected, then shows the moment six ways: a plain-English UTC date, the ISO 8601 string developers paste into code, your browser's local interpretation, the timestamp restated in both seconds and milliseconds, and a relative label like "212 days ago" or "3 hours from now". The Use current timestamp button fills in the live epoch time so you can see exactly what "now" looks like as a number.

Working date → timestamp: pick a calendar date and a time in the second section and the Unix timestamp appears below in seconds and milliseconds, with the UTC equivalent shown for confirmation. Times are interpreted in your local timezone — if you need the timestamp for midnight UTC instead, set the time field with your UTC offset in mind (for example, enter 19:00 while on US Eastern time in winter to hit 00:00 UTC).

What Is a Unix Timestamp? How It Works

A Unix timestamp — also called epoch time — counts the seconds elapsed since 00:00:00 UTC on January 1, 1970, the "Unix epoch". January 2, 1970 at midnight UTC is 86,400 (one day of 86,400 seconds); today the counter sits near 1.78 billion. The genius of the format is that it is timezone-free: the number 1767225600 names one exact instant, and whether you are in New York, London or Sydney you convert it to your local wall-clock time the same way.

Two flavors exist. Seconds (10 digits) is the classic format used in databases, JWT tokens and most APIs. Milliseconds (13 digits) is what JavaScript's Date.now() returns and what many modern web APIs expect. Mixing them up is the most common bug in timestamp handling — a millisecond value read as seconds lands you in the year 58,000, while a second value read as milliseconds lands you in January 1970. This converter detects the unit from the digit count so a paste mistake is obvious immediately.

Worked Example

Take the timestamp 1767225600 and convert it step by step:

Try it above: paste 1767225600 and you will see January 1, 2026 at midnight UTC, plus your local equivalent — 7:00 PM on December 31, 2025 if you are on US Eastern Standard Time. Then use the date section to convert 2026-01-01 back and watch the same number come out. Round-tripping like this is the fastest way to confirm your code and your converter agree.

Seconds vs. Milliseconds, the 2038 Problem & Timezone Traps

Three things bite developers with epoch time, and they bite in this order. First, the unit mix-up: always check digit count. A 10-digit number is seconds; 13 digits is milliseconds; anything else is probably a bug. When an API documents "timestamp", confirm which one — Stripe uses seconds, JavaScript's Date uses milliseconds, and plenty of Stack Overflow threads exist because someone divided by 1,000 twice.

Second, the Year 2038 problem: systems storing timestamps in a signed 32-bit integer overflow at 2,147,483,647 seconds (January 19, 2038, 03:14:07 UTC) and wrap into negative numbers — dates in 1901. Modern 64-bit systems are immune, but old embedded devices and file formats are not. Third, timezone traps: the timestamp itself has no timezone, but the moment you render it as "January 1", a timezone sneaks in. Bugs cluster around daylight-saving transitions, where 2:30 AM happens twice or not at all. When in doubt, store and compare in epoch seconds and convert to local time only at the display layer.

Limitations

This converter handles the standard Unix epoch range that JavaScript dates support (roughly ±275,000 years) and auto-detects seconds vs. milliseconds by digit count — unusual formats like microseconds (16 digits) or nanoseconds (19 digits) will be misread, so divide those down first. The date-to-timestamp section interprets your input in the browser's local timezone; it does not currently let you pick an arbitrary timezone for that direction.

Leap seconds are ignored, as they are by Unix time itself: the timestamp 1767225600 assumes every day has exactly 86,400 seconds, which can drift by a second from precise astronomical time. Results are for development and planning convenience — always validate critical scheduling logic in your own environment, especially around daylight-saving boundaries.

Timestamps turn up wherever media and logs meet. Podcasters stamping chapters hit the same wall from the other side: the Podcast Chapter Marker exports those marks as YouTube chapters or Podcasting 2.0 JSON. And when a log line or filename arrives in the wrong case, the text case conversion guide explains the four case styles and which one a filename should wear.

Guides for This Tool

Frequently Asked Questions

Related Tools