Unix Timestamp Converter

What Is This Tool?

A Unix timestamp (also called epoch time) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. It's the standard way computers store points in time: databases, log files, APIs and programming languages all use it because it's a single unambiguous number with no timezone confusion.

Two flavors exist: seconds (10 digits today, e.g. 1720500000) and milliseconds (13 digits, used by JavaScript and Java). This tool detects which one you pasted automatically.

Why Use It?

• Read timestamps from logs, database rows and API responses instantly.
• Auto-detects seconds vs milliseconds — no guessing.
• Shows local time, UTC, ISO 8601 and relative time ("3 hours ago") together.
• Convert in both directions: timestamp → date and date → timestamp.
• Live current-epoch clock for quick reference.

How to Use

1. To decode: paste a timestamp (like 1720500000) into the left box and click "Convert".
2. Read the result in your local timezone, UTC, ISO 8601 and as relative time.
3. To encode: pick a date and time in the right box and click "Convert" to get its timestamp in seconds and milliseconds.
4. Use the live clock at the top when you just need the current timestamp.

Example

Input

1720500000

Output

Local time: 7/9/2024, 1:20:00 PM
UTC time:   Tue, 09 Jul 2024 05:20:00 GMT
ISO 8601:   2024-07-09T05:20:00.000Z

A 10-digit value is treated as seconds; a 13-digit value as milliseconds.

Practical tips

• Debugging "wrong time" bugs: 90% are timezone display issues, not wrong timestamps. Compare the UTC row against your server logs (servers usually log UTC) before touching any code.
• A date that lands exactly on 1970-01-01 means the timestamp was 0 or missing — a classic null-value symptom, not a real date.
• A date around 1970 + a few days usually means seconds were interpreted as milliseconds somewhere; a date in the year 56,000+ means the reverse.
• In spreadsheets: Excel counts days since 1900, not seconds since 1970. Convert with =(A1/86400)+DATE(1970,1,1) for a seconds timestamp.

Real usage scenarios

Where timestamps bite in practice: reading expiry fields in JWTs and API tokens (exp/iat are Unix seconds), correlating a user's bug report time with server log lines, setting cache TTLs and cron windows, and checking whether a certificate or token has actually expired. The relative-time row ("3 hours ago") is the fastest sanity check for all of these.

JWT debugging is common enough to spell out: decode the token's payload with the Base64 tool, then paste the exp value here — instant answer to "is this token expired and by how much".

Why Unix time was designed this way

Storing a single incrementing number since a fixed epoch (rather than a year/month/day/hour structure) was a deliberate simplicity trade: two timestamps can be compared or subtracted with plain arithmetic, no calendar logic required, which is why databases, log formats, and virtually every programming language's internal date representation are built on it. The cost of that simplicity is exactly what this tool exists to smooth over — humans don't think in seconds-since-1970, so every timestamp needs translating back into a calendar date before it means anything to a person reading it, and that translation has to account for timezone, precision (seconds vs milliseconds), and display format all at once.

→ Base64 Encoder / Decoder · Age Calculator

Frequently Asked Questions