Unix Timestamp Converter – Epoch to Date Tool

You are reading through an error log and see 1700000000. Or you decode a JWT and find an exp claim of 1700036000 and need to know whether the token has already expired. Or an API response includes a created_at field with ten digits and no timezone, and you need to figure out what date that actually represents. These are all Unix timestamps — and without a converter, reading them means mental arithmetic against an arbitrary epoch date that nobody has memorised. A Unix timestamp converter online turns any of those numbers into a human-readable date in one paste.

Unix time is everywhere in software: database records, log files, JWT claims, OAuth tokens, S3 object metadata, scheduled job outputs. Understanding what a timestamp means — and spotting when one is wrong — is a basic debugging skill. This guide covers what Unix time is, why it works the way it does, and the issues that catch developers out most often.

# Unix epoch: seconds elapsed since 1970-01-01 00:00:00 UTC

1700000000  →  2023-11-14 22:13:20 UTC  (seconds — 10 digits)
1700000000000  →  2023-11-14 22:13:20 UTC  (milliseconds — 13 digits)

# JWT expiry claim — is this token still valid?
{ "exp": 1700036000 }  →  2023-11-14 23:13:20 UTC
# If now > 2023-11-14 23:13:20 UTC → token is expired

# Converting in code:
# JavaScript:  new Date(1700000000 * 1000).toISOString()
# Python:      datetime.utcfromtimestamp(1700000000)
# SQL:         FROM_UNIXTIME(1700000000)   -- MySQL
#              TO_TIMESTAMP(1700000000)    -- PostgreSQL

What Is a Unix Timestamp?

A Unix timestamp is a single integer representing a point in time — specifically, the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC, an arbitrary reference point known as the Unix epoch. The choice of 1970 dates back to the early Unix systems; it has no particular significance beyond being the convention every major operating system, language, and database now shares.

The appeal of Unix time is its simplicity. A timestamp is just a number. Comparing two timestamps to see which is earlier is a single integer comparison. Calculating the difference between two points in time is subtraction. Storing a timestamp requires no timezone metadata, no locale-specific formatting, and no ambiguity about calendar conventions. Every system that understands Unix time agrees on what any given integer means.

The most important thing to know is that Unix timestamps are always in UTC. There is no such thing as a Unix timestamp "in Pacific time." The integer represents an absolute moment in time. Converting it to a local time for display is a separate step — one that depends on the viewer's timezone, not on the timestamp itself.

Why Developers Use Epoch Time

Databases and APIs almost universally store time as Unix timestamps or ISO 8601 strings. Unix time has specific advantages that explain its continued dominance.

• Unambiguous across timezones. A timestamp of 1700000000 means exactly one point in time, regardless of where the server, the database, or the client is located. Storing times as local datetimes introduces ambiguity during daylight saving transitions and creates bugs when servers in different regions exchange data.
• Efficient storage and indexing. A 32-bit or 64-bit integer is smaller and faster to index than a formatted datetime string. For high-volume event tables and log systems, this matters.
• Easy arithmetic. "Events from the last 24 hours" is WHERE created_at > now() - 86400. No date parsing, no timezone conversion, no edge cases around month boundaries.
• JWT and OAuth expiry claims. The exp, iat, and nbf claims in a JWT are all Unix timestamps. When you decode a token and see a number in the expiry field, converting it tells you exactly when the token expires — and whether a 401 you are debugging is an expired token or a signature mismatch.

How to Convert a Timestamp Online

Using the DevToolBox Timestamp Converter takes under ten seconds.

1. Open the tool in your browser. No account, no install, no setup required.
2. Paste your Unix timestamp into the input field. The tool accepts both seconds (10 digits) and milliseconds (13 digits) and detects the format automatically.
3. The converted date and time appears immediately — in UTC and in your local timezone, so you can see both representations at once.
4. To go the other direction, enter a date and time and the tool converts it to a Unix timestamp — useful when you need to construct a query or set an expiry value.

DevToolBox tools run entirely in your browser — no signup, no data sent to a server.

Common Timestamp Issues

# ✗ Seconds vs milliseconds confusion — the most common bug:
new Date(1700000000)      →  1970-01-20 (treated as milliseconds — wrong)
new Date(1700000000 * 1000) →  2023-11-14 (correct)

# ✗ Storing local time as if it were UTC:
# User in UTC+9 creates record at 09:00 local = 00:00 UTC
# Stored as 1700000000 (UTC midnight) — correct
# Displayed without conversion → shows 00:00 to everyone — wrong for other zones

# ✗ 2038 problem — 32-bit signed integer overflow:
# Max value: 2147483647 → 2038-01-19 03:14:07 UTC
# Systems still using 32-bit timestamps will overflow on this date
# Fix: use 64-bit integers (already the default in most modern systems)

# ✓ Always store UTC, convert to local at display time
# ✓ Check digit count: 10 = seconds, 13 = milliseconds

• Seconds vs milliseconds. This is the most common Unix timestamp bug. JavaScript's Date constructor and many browser APIs work in milliseconds. Most Unix tools, databases, and backend languages work in seconds. Passing a seconds-based timestamp to a milliseconds-based API — or vice versa — produces dates in 1970 or 56,000 years in the future. Count the digits: 10 is seconds, 13 is milliseconds.
• Assuming local time. A Unix timestamp is always UTC. Displaying it as a local time requires an explicit conversion. Skipping the conversion in a server-rendered application means users in different timezones see the wrong time — or the same wrong time regardless of their location.
• Daylight saving edge cases. Timestamps sidestep most DST issues because they are UTC-based. The problem arises when converting back to local time: the same UTC timestamp can correspond to two different local times during the hour a clock is set back. Use a reliable timezone library (Luxon, date-fns-tz, pytz) rather than manual offset arithmetic.
• The 2038 problem. A 32-bit signed integer can hold Unix timestamps only up to 2038-01-19. Systems and databases still using 32-bit timestamp columns will overflow on that date. Most modern systems default to 64-bit integers, but legacy databases and embedded systems may still be affected. It is worth checking if your schema uses INT vs BIGINT for timestamp columns.

Frequently Asked Questions

Conclusion

Unix timestamps are simple in principle and surprisingly easy to get wrong in practice — mostly because of the seconds-vs-milliseconds split and the assumption that a number without context is automatically in your local timezone. Knowing to count the digits and to always think in UTC eliminates the majority of timestamp bugs before they happen.

When you need to quickly convert a timestamp from a log, a JWT claim, or an API response, the DevToolBox Timestamp Converter handles both seconds and milliseconds and shows UTC alongside your local time. DevToolBox tools run entirely in your browser — no signup, no install, nothing sent to a server.