What is a Unix timestamp converter?
A Unix timestamp converter translates between machine-friendly epoch numbers and human-readable calendar dates. Logs, databases, REST APIs, and message queues often store time as an integer - seconds or milliseconds since 1 January 1970 UTC - because integers sort correctly, compress well, and avoid timezone ambiguity at storage time.
The problem is readability. Seeing 1704067200 in a log line tells you almost nothing until you convert it. This tool does that instantly: paste a timestamp and see ISO 8601, UTC, local time, and both second and millisecond forms update live. Or pick a date and time with the datetime picker and get the corresponding Unix value.
Toggle between seconds and milliseconds, switch conversion direction with one click, and copy any field individually or all formats at once. No install, no API key, no data leaving your browser.
How to use the Unix timestamp converter
- Choose a direction. Select Timestamp to date to interpret an epoch number, or Date to timestamp to go the other way.
- Set the unit. Pick Seconds or Milliseconds to match the format your API or database uses.
- Enter a value. Type a numeric timestamp or use the datetime picker. Click Load sample to try a known example.
- Read the live output. ISO, UTC, local, and Unix forms update as you type. Copy any single field or use Copy all for a full summary.
Examples
Seconds to date
Input: 1704067200 (seconds)
ISO: 2024-01-01T00:00:00.000Z
UTC: Mon, 01 Jan 2024 00:00:00 GMT
Local: (depends on your timezone)This is midnight UTC on New Year's Day 2024. Your local field shifts according to the timezone configured in your operating system and browser.
Date to milliseconds
Input: 2024-01-01T00:00 (local datetime picker)
Output: 1704067200000 (if your local offset is UTC)The datetime-local control interprets the value in your local timezone. That is why the same wall-clock time produces different epoch numbers for users in different regions - always note whether an API documents its timestamps as UTC or local.
Seconds vs milliseconds in real systems
Unix time in seconds is the traditional POSIX format. You will find it in PostgreSQL EXTRACT(EPOCH FROM ...) results, many Linux utilities, Python's time.time(), and older REST APIs. Milliseconds (or sometimes microseconds) appear in JavaScript Date.now(), MongoDB ObjectId timestamps, Elasticsearch, and several Java and Node.js frameworks where sub-second precision matters.
Mixing units is one of the most common timestamp bugs. A value that looks like a valid seconds timestamp becomes nonsense when treated as milliseconds, and vice versa. When debugging, check the digit count first, then confirm against a known reference instant like the epoch itself (0 = 1970-01-01 UTC).
ISO 8601, UTC, and local time
The ISO 8601 field uses the toISOString() format ending in Z, which unambiguously means UTC. The UTC field shows the same instant in the RFC-friendly string browsers produce with toUTCString(). The Local field applies your system timezone offset, which is what you usually want when correlating logs with wall-clock times on your machine.
When sharing timestamps across teams, prefer ISO 8601 with an explicit offset or Z suffix. Plain local strings without offset information cause recurring confusion across daylight saving changes and international collaborators.
Tips for working with epoch time
- Confirm the unit in API documentation before converting - do not rely on digit count alone for values near the epoch.
- Store and transmit instants in UTC; convert to local time only at display time.
- When a JSON payload mixes epoch fields with ISO strings, format it with the JSON Formatter first so field names are easy to scan.
- For encoded query parameters that carry timestamps, decode them with the URL Encoder Decoder before converting here.
- Log correlation often pairs timestamps with UUIDs - generate test IDs with the UUID Generator when building fixtures.