Computers count time as a single number: the seconds (or milliseconds) elapsed since 00:00:00 UTC on 1 January 1970 — the Unix epoch. That number, the Unix timestamp, appears everywhere: JWT expiries, database created_at columns, API responses, log files, and file metadata. It is compact, timezone-free, and trivial to compare or sort.
Humans, however, cannot read it. 1788393600 means nothing at a glance, yet it might be the expiry of the token blocking your users, or the moment a critical event occurred. Converting between that number and a calendar date is one of the most frequent micro-tasks in debugging, and doing it by hand (or with mental arithmetic) is slow and error-prone.
This free Unix timestamp converter works in both directions: paste a timestamp to see the UTC and local date, or type a date to get the timestamp in seconds and milliseconds. A “now” button grabs the current moment, and a unit toggle handles the eternal seconds-vs-milliseconds confusion.
How to use the Unix timestamp converter
- Timestamp → date: paste the number, choose seconds or milliseconds, and click convert.
- Read both zones: the result shows UTC and your local time side by side — the mismatch between them causes half of all timestamp bugs.
- Date → timestamp: type a date like
2026-01-15 14:30:00(local time) or ISO format withZfor UTC. - Use “now” to capture the current timestamp instantly for logs, tokens, or test data.
- Debugging a JWT? Paste its
expclaim here after decoding with our JWT decoder.
Key features & benefits
- Both directions. Timestamp-to-date and date-to-timestamp in one tool — no tab switching.
- Seconds and milliseconds. A unit toggle ends the “is this 10 or 13 digits?” guessing game.
- UTC + local display. See both interpretations together and catch timezone mistakes immediately.
- Flexible date parsing. Accepts
2026-01-15 14:30:00, ISO 8601, and other common formats. - One-click “now”. Grab the current epoch time for seeding test data or stamping logs.
- Friendly errors. Non-numeric input and unparseable dates get clear guidance, not silent NaNs.
Avoiding the classic timestamp traps
Three mistakes cause the overwhelming majority of timestamp bugs:
Seconds vs. milliseconds
JavaScript’s Date.now() returns milliseconds (13 digits); most APIs and JWTs use seconds (10 digits). Mixing them up puts you in the year 51380 or back in 1970. Count the digits: 10 means seconds, 13 means milliseconds — and this tool’s toggle converts either. Timestamps are just numbers — our number base converter shows their binary and hex forms.
Timezone assumptions
Epoch time itself has no timezone, but the moment you format it, one applies. A timestamp that means midnight UTC is still yesterday evening in New York. Always check whether your system stores UTC (it should) and convert to local only for display. When scheduling across zones, our UUID generator is handy for the unique ids those events often need.
The year 2038 problem
Signed 32-bit seconds overflow on 19 January 2038 — still lurking in old embedded systems and file formats. Modern 64-bit systems are fine, but if you maintain legacy code, this is worth a calendar reminder. For date math in application code, prefer your language’s date library over raw arithmetic.
Unix Timestamp to Date
Converting a Unix timestamp to a date is the most common job this tool handles: paste any 10-digit timestamp in seconds or 13-digit timestamp in milliseconds, and it instantly shows the readable date and time in both UTC and your local timezone. It works the other way too — type a date to get its timestamp. Developers use it every day for debugging API responses, reading server logs, and checking database values.
Frequently asked questions
What is the Unix epoch?
It is the reference moment from which Unix time is counted: midnight UTC on 1 January 1970. A timestamp of 0 means exactly that instant; negative values represent earlier dates. The choice was arbitrary but is now baked into virtually every system.
Why does my timestamp have 13 digits?
It is in milliseconds — the JavaScript convention (Date.now()). Divide by 1000 (dropping the remainder) to get seconds. This tool’s unit toggle handles the conversion both ways, so just select “milliseconds” and convert.
Does the converter account for leap seconds?
No — and neither does Unix time itself. By definition, every UTC day is exactly 86,400 seconds long, so leap seconds are smeared or ignored depending on the system. For sub-second scientific precision you need TAI or a specialized library, not epoch time.
How do I convert a timestamp in Python / JavaScript?
In Python: datetime.fromtimestamp(1788393600, tz=timezone.utc). In JavaScript: new Date(1788393600 * 1000) (note the ×1000 for milliseconds). Going the other way: Python’s int(d.timestamp()) or JS Math.floor(date.getTime() / 1000).
Is the “local” time shown in my timezone?
Yes — it uses your browser’s timezone setting, whatever your operating system reports. If you are debugging for users in another zone, the UTC value is the unambiguous reference to share.
How do I convert a Unix timestamp to a date?
Paste the timestamp into the converter above — it instantly shows the human-readable date and time, free with no signup.
How It Works: Under the Hood
A Unix timestamp counts seconds since 1970-01-01T00:00:00 UTC (the “epoch”), ignoring leap seconds. Converting a human date means computing the exact second offset: days since epoch × 86,400, plus hours/minutes/seconds, adjusted by the timezone’s UTC offset — including daylight-saving rules for that specific date (New York is UTC-5 in January but UTC-4 in July). The reverse direction divides the timestamp back into calendar units using the proleptic Gregorian calendar.
The classic gotcha is seconds vs milliseconds: JavaScript’s Date.now() returns milliseconds (13 digits, e.g. 1727000000000), while Unix timestamps are seconds (10 digits, 1727000000). The tool detects the magnitude automatically — anything above ~1e12 is treated as milliseconds. And yes, the Year 2038 problem is real: 32-bit signed timestamps overflow on 2038-01-19. Modern systems use 64-bit, but embedded devices and old databases still carry the risk.
Real-World Use Cases
- Debugging APIs: a developer sees
"created_at": 1727000000in a JSON response and converts it instantly to check whether a record is fresh or stale. - Log forensics: server logs stamp events in epoch time; converting a cluster of timestamps reveals the exact human timeline of an outage.
- Database migrations: moving between MySQL
DATETIMEand MongoDB epoch fields requires bulk conversion — spot-check individual values here first. - Cron scheduling: verifying that a cron job set for “next Tuesday 3 AM” in a specific timezone maps to the right epoch before deploying.
- JWT debugging: the
expandiatclaims in JSON Web Tokens are Unix timestamps — convert them to see if a token is expired or issued in the future (clock skew).
Advanced Tips
- Always note the timezone. “2026-09-29 11:30” is meaningless without a zone — it could be six different moments. Convert with the source’s zone explicitly, especially across DST boundaries.
- Use UTC for storage, local for display. The golden rule of time handling: store epoch/UTC, convert to the viewer’s timezone only at render. This tool is how you verify the conversions.
- Watch for the 2038 boundary in old systems. If you’re working with 32-bit embedded timestamps, test dates past 2038-01-19 now — better to find the overflow in testing than in production.
- Distinguish epoch variants. .NET ticks, Excel serial dates, and LDAP timestamps all count from different epochs. Convert to Unix epoch first as the common denominator.
Common Mistakes to Avoid
- Mixing seconds and milliseconds. Feeding milliseconds where seconds are expected gives you a date in the year 56,000+. Count the digits: 10 = seconds, 13 = milliseconds.
- Forgetting DST exists. A timestamp converted in January vs July for the same wall-clock time in New York differs by an hour. Always convert with the date’s actual offset, not a fixed one.
- Assuming local time is UTC. Server logs in UTC vs your laptop in PKT (UTC+5) differ by 5 hours — “the event happened at 3 AM” means very different things. Convert, don’t guess.
- Using timestamps for human deadlines. “Expires 1727000000” in a contract is asking for disputes. Timestamps are for machines; humans need “October 15, 2026, 5:00 PM PKT.”
When You Actually Need a Timestamp Converter
Timestamp math shows up everywhere: debugging API responses that return 10-digit integers, reading expiry values in JSON Web Tokens with the JWT decoder, writing cron schedules, and converting database DATETIME columns for log comparison. The golden rule: count the digits — 10 digits means seconds, 13 means milliseconds. The most common bug in timestamp code is mixing the two and landing on a date in 1970 or the year 50,000. When you need human time math instead, the date duration calculator measures gaps between calendar dates directly.