Unix Timestamp Converter
Convert between Unix timestamps and human-readable dates instantly. See the live current epoch time — essential for debugging TOTP, JWTs, and API tokens.
⏰ Why Timestamps Matter for 2FA
TOTP codes are generated using Unix timestamps divided into 30-second windows. A clock even slightly out of sync will cause code mismatches.
🔑 JWT Debugging
JWTs use iat, exp, and nbf claims as Unix timestamps. Use this tool to decode when a token was issued and when it expires.
🌍 Timezone-Safe
Unix timestamps are always UTC — no timezone ambiguity. This makes them the universal standard for APIs, databases, and security tokens.
Frequently Asked Questions
What is a Unix timestamp?
A Unix timestamp is the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC — also called the Unix epoch. It's a timezone-agnostic way to represent any moment in time, used universally in programming, APIs, databases, and security protocols.
Why does TOTP use Unix timestamps?
TOTP (Time-based One-Time Password) codes are generated by dividing the current Unix timestamp by 30 to get a "window" number, then combining that with your secret key via HMAC-SHA1. Both your authenticator app and the server independently calculate the same window, so they always produce the same code — without communicating.
What's the difference between seconds and milliseconds timestamps?
Unix timestamps are traditionally in seconds (10 digits today). JavaScript's Date.now() returns milliseconds (13 digits). TOTP and most security protocols use seconds. APIs vary — always check the documentation. If your timestamp has 13 digits, divide by 1000 to get seconds.
What is the Year 2038 problem?
32-bit signed integers can store Unix timestamps up to 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. After that point, 32-bit systems will overflow. Modern systems use 64-bit integers, which won't overflow for billions of years.
What does a negative Unix timestamp mean?
Negative timestamps represent moments before the Unix epoch (January 1, 1970 at 00:00:00 UTC). For example, -86400 is exactly December 31, 1969. This tool converts negative values correctly, which is useful when working with historical data or birth dates stored as epoch time.
How do I get the current Unix timestamp in code?
In JavaScript use Math.floor(Date.now() / 1000), because Date.now() returns milliseconds. In Python use int(time.time()), in PHP use time(), and in Bash use date +%s. All of these return seconds since the epoch, which is what TOTP and JWT libraries expect.
Do Unix timestamps account for leap seconds?
No. Unix time counts elapsed seconds using a fixed 86400-second day, so leap seconds are ignored. The tiny drift this introduces is irrelevant for TOTP, JWT, and API timestamp use — the key thing is that both sides of a comparison agree on the same convention.
Is a Unix timestamp affected by time zones?
No. A Unix timestamp is an absolute count of seconds since the epoch in UTC, so the same number represents the same instant everywhere on Earth. Time zones only affect how that number is rendered as a local date and time — which is exactly why this tool always shows both UTC and your local timezone.
How to use the Unix timestamp converter
- Read the live timestamp. The top of the tool shows the current epoch time in seconds, updating every second, along with its UTC representation and the current TOTP window. Use this as a reference when comparing values from an API or database.
- Convert a timestamp to a date. Paste a Unix timestamp into the "Unix Timestamp → Human Date" field. The tool auto-detects 13-digit millisecond values and converts them to seconds, then shows the date in UTC, your local timezone, ISO 8601 format, and a relative "3h ago" style readout.
- Convert a date to a timestamp. Pick a date and time in the "Human Date → Unix Timestamp" field to get both the seconds and millisecond representations, ready to paste into code.
- Use the TOTP window readout. The tool also reports which 30-second TOTP window the timestamp falls in. When a TOTP code fails unexpectedly, check the window of the timestamp your server used against the window your authenticator app uses — a mismatch usually means clock drift.
Common timestamp mistakes and how to avoid them
- Confusing seconds with milliseconds. Seconds timestamps are 10 digits today; milliseconds are 13. Mixing them up produces dates in 1970 or 5138 — a classic bug in every language. This tool detects the length automatically, but in your own code check your source's unit first.
- Treating local time as UTC. The timestamp itself is timezone-free, but if you convert it with code that assumes local time, the displayed date shifts. Always convert with UTC-aware functions and reserve local time for display.
- Using 32-bit integers. Languages like older C code and some embedded environments store timestamps in 32-bit integers, which overflow in January 2038. If you store timestamps long-term, use 64-bit fields from the start.
- Storing dates as strings. A string like "05/06/2027" is ambiguous — is it May 6 or June 5? A timestamp is unambiguous, comparable, and sortable, which is why APIs, JWT tokens, and TOTP all rely on it.
- Ignoring clock drift for TOTP. TOTP verification usually tolerates ±1 window (30 seconds) of clock skew. If codes keep failing, compare your server clock to the live timestamp here — even a few seconds of drift can eat into the tolerance window during high-traffic periods.