Unix Timestamp Converter
Unix timestamps are compact, language-neutral values for representing moments in time. They appear in logs, analytics events, API responses, cache headers, database exports, and command-line tools. Reading them directly is not pleasant, especially when you need to know whether a value is in seconds or milliseconds. The CodeToolia Timestamp Converter lets you convert Unix time into a readable date and convert a local date-time value back into seconds and milliseconds. It is useful when debugging scheduled jobs, checking token expiration times, comparing log entries, or preparing examples for documentation. The conversion runs in the browser and uses your environment for local date display, while also showing an ISO timestamp so the moment can be compared consistently across systems. Always pay attention to time zones when copying values between tools.
Output
Converted date will appear here.
Output
Converted timestamp will appear here.
About Unix Timestamp Converter
Convert Unix timestamps to dates and dates back to Unix time. This utility is part of CodeToolia, a collection of tools designed to simplify web development workflows. Like all our utilities, this tool operates entirely on the client side, meaning your data is processed locally within your browser and is never transmitted to any server.
Privacy & Security
We prioritize your privacy. By using browser-based technologies (Web APIs), we ensure that sensitive data—such as API keys, JSON payloads, or personal identifiers—stay strictly within your local environment.
How to use
- Enter a Unix timestamp in seconds or milliseconds and convert it to a readable date.
- Pick a date and time to generate Unix timestamps.
- Use the ISO output when you need a timezone-stable representation.
How this tool works
The converter treats Unix time as a count from 1970-01-01T00:00:00Z and helps separate two common representations: seconds and milliseconds. Many bugs happen because a value such as 1704067200 is read as milliseconds, or 1704067200000 is read as seconds.
The page shows both local display and ISO output so you can compare what a user sees with the UTC moment that servers, logs, and APIs usually exchange.
Common use cases
Check token expiration claims, cache timestamps, analytics events, and scheduled job logs without writing a one-off date script.
Convert a planned release time or test appointment into Unix seconds and milliseconds for API payloads, database rows, or configuration files.
Example
Unix seconds 1704067200 represents 2024-01-01T00:00:00.000Z.
Accuracy and privacy notes
Local time depends on the device running the browser. When sharing a result with another team, include the ISO timestamp if the exact instant matters.
Some platforms store timestamps in seconds while JavaScript Date uses milliseconds. Confirm the expected unit before pasting a value into production configuration.
Timestamp Converter technical guide
Learn the concept behind this tool, when developers use it, and how to reproduce the same operation in code.
What is a Unix timestamp?
A Unix timestamp is a numeric representation of a moment in time. Instead of storing a date as a phrase such as January 1, 2026 at 09:30, a Unix timestamp stores the number of seconds or milliseconds that have elapsed since 1970-01-01 00:00:00 UTC. That reference moment is called the Unix epoch. It became the standard because early Unix systems needed a compact, timezone-neutral way to compare file modification times, process events, logs, and scheduled jobs. Counting from one fixed UTC instant is much easier for computers than storing calendar words, month names, daylight-saving rules, and local timezone labels.
The year 1970 is not special in a calendar sense; it is a historical engineering choice from Unix. What matters is that every participating system agrees on the same zero point. If two servers use Unix time, they can compare events with simple numeric ordering: a larger value happened later, a smaller value happened earlier, and the difference between two values gives a duration. This is why timestamps appear in APIs, databases, JWT tokens, analytics events, message queues, cache headers, CDN logs, and background job systems.
The most common trap is the difference between seconds and milliseconds. Many backend APIs, Unix command-line tools, PostgreSQL extracts, JWT claims, and Python examples use seconds. JavaScript Date uses milliseconds. A timestamp such as 1704067200 is 2024-01-01T00:00:00Z when treated as seconds, but it points to a date in January 1970 if JavaScript reads it as milliseconds. A timestamp such as 1704067200000 is the same instant in milliseconds, but it becomes a far-future date if a seconds-based system reads it directly.
Another important detail is integer size. The classic 32-bit signed Unix timestamp reaches its maximum at 2038-01-19 03:14:07 UTC. Older systems that store seconds in a signed 32-bit integer can overflow after that moment, a problem often called the Year 2038 problem. Modern 64-bit systems avoid this limit for practical software lifetimes, but legacy embedded systems, old databases, and binary file formats can still contain 32-bit timestamp assumptions. When designing new systems, prefer explicit 64-bit storage and document whether the value is seconds, milliseconds, microseconds, or nanoseconds.
Common developer use cases
Developers use a timestamp converter when raw time values appear without enough context. Backend API responses often include fields such as created_at, expires_at, issued_at, updatedAt, or event_time. If a request feels slow, timestamps in logs can reveal whether the delay happened in the browser, at the edge, in the application server, or inside a database query. Converting those values quickly helps you build a timeline without writing a temporary script.
JWT debugging is another frequent use case. JSON Web Tokens commonly include exp, iat, and nbf claims. These values are usually Unix seconds. If a token is rejected, a timestamp converter lets you check whether the token has expired, was issued in the future because of clock skew, or is not valid yet. This is especially useful when frontend, backend, and identity provider servers run in different environments.
Database exports and analytics logs also benefit from conversion. A CSV export may contain seconds, milliseconds, or database-specific epoch values. Observability tools may show ISO timestamps while application payloads use numeric values. A converter gives you a neutral way to compare them. It is also handy when preparing test data: you can choose a human date, convert it into both seconds and milliseconds, and paste the correct value into a fixture, migration, cache test, or scheduled job configuration.
Code examples
The safest habit is to name variables with their unit: timestampSeconds, timestampMillis, expiresAtSeconds, or createdAtMillis. The code below shows the same operation in common languages so you can compare how each runtime handles the unit boundary.
JavaScript: seconds and milliseconds
javascriptconst seconds = 1704067200;
const fromSeconds = new Date(seconds * 1000);
console.log(fromSeconds.toISOString());
const millis = Date.now();
console.log(Math.floor(millis / 1000));
console.log(new Date(millis).toISOString());Python: convert Unix time
pythonfrom datetime import datetime, timezone
seconds = 1704067200
print(datetime.fromtimestamp(seconds, tz=timezone.utc).isoformat())
now_seconds = int(datetime.now(tz=timezone.utc).timestamp())
print(now_seconds)Java: Instant and epoch values
javaimport java.time.Instant;
long seconds = 1704067200L;
Instant instant = Instant.ofEpochSecond(seconds);
System.out.println(instant.toString());
long millis = Instant.now().toEpochMilli();
System.out.println(millis);Go: Unix seconds and milliseconds
gopackage main
import (
"fmt"
"time"
)
func main() {
seconds := int64(1704067200)
fmt.Println(time.Unix(seconds, 0).UTC().Format(time.RFC3339))
millis := time.Now().UnixMilli()
fmt.Println(millis)
}FAQ and troubleshooting
Why is my local time eight hours different from the ISO time? ISO strings ending in Z are displayed in UTC. Your browser local time uses your device timezone, such as Asia/Shanghai, which is UTC+08:00. The instant is the same; only the presentation changes. For example, 2024-01-01T00:00:00Z appears as 2024-01-01 08:00:00 in China Standard Time.
Why does my converted date look like 1970? That usually means a seconds value was treated as milliseconds. JavaScript's Date constructor expects milliseconds, so Unix seconds must be multiplied by 1000. The reverse problem creates dates thousands of years in the future when milliseconds are accidentally sent to a seconds-based API.
Should I store timestamps or formatted date strings? For system fields, store a precise timestamp or a database-native timestamp type, and format it only at the edge of the application. Formatted strings are useful for display, but numeric or native timestamp values are easier to sort, compare, index, and convert between timezones.
FAQ
What is the difference between seconds and milliseconds?+
Seconds count whole seconds since 1970-01-01 UTC. Milliseconds are 1,000 times more precise.
Why does my local time look different from UTC?+
Local display uses your device time zone. ISO output uses UTC with a Z suffix.
Can timestamps represent dates before 1970?+
Yes. Negative Unix timestamps represent moments before 1970-01-01 UTC.