Millisecond Timestamp Converter
Convert between Unix millisecond timestamps (13 digits) and human-readable dates. The default format for JavaScript Date.now() and modern JSON APIs.
Timestamp → Date
4/23/2026, 12:03:48 PMThu, 23 Apr 2026 12:03:48 GMT2026-04-23T12:03:48.437ZDate → Timestamp
About Millisecond Timestamp
Millisecond-precision Unix timestamps (the 13-digit values produced by JavaScript's Date.now()) are the default format for modern web APIs, WebSocket ping/pong, real-time event systems, and anything that needs sub-second precision without the complexity of nanosecond fields. This converter pre-fills the input with the current Date.now() value and emphasises millisecond output alongside the classic seconds representation. The second-vs-millisecond choice matters in a few places: JavaScript (Date.now() and new Date(ms)) always uses milliseconds. Most REST APIs that accept a timestamp in a JSON body use milliseconds. Most databases that store timestamps as an integer use seconds (except where explicitly ms — some MongoDB and CouchDB setups, InfluxDB with a precision setting). Most Unix CLI tools (date +%s, cron @reboot) use seconds. When two systems disagree — a JavaScript frontend sending ms, a Python backend expecting seconds — bugs appear as 1000× or 1/1000× date drift, often misdiagnosed as timezone issues. This variant is optimised for the JS-native case: the input starts populated with "right now in ms", the output shows ms first, and the seconds output is still there for interop. Paste any 13-digit number and get the date; pick a date and get the ms value.
Features
- Convert Unix timestamps to human-readable dates
- Convert dates to Unix timestamp format
- Support for multiple date formats and timezones
- View the current timestamp in real-time
How to Use
- Enter a Unix timestamp or select a date
- View the converted result in the other format
- Choose your preferred date format and timezone
- Copy the converted value to clipboard
Frequently Asked Questions
Why is my API timestamp 1000× bigger than expected?
Almost always a seconds/milliseconds mismatch. JavaScript produces milliseconds (13 digits); many backends assume seconds (10 digits). Divide by 1000 to convert ms → s, or multiply to go the other way. If the date lands around 1970 or 50,000 years in the future, you've got the unit wrong.
Is milliseconds precision enough for event ordering?
Usually yes — two events in the same millisecond are rare in most apps. For high-frequency systems (trading, ad-bidding), add a per-process counter or use a UUID v7 which embeds a ms timestamp plus 74 random bits. For nanosecond precision, use Date.now() + performance.now() or a native API.
Do database timestamp columns store milliseconds or seconds?
Depends on the database and column type. Postgres TIMESTAMP and TIMESTAMPTZ store microseconds internally. MySQL DATETIME(3) stores milliseconds; plain DATETIME is seconds. MongoDB Date is milliseconds. ALWAYS confirm by reading docs — wrong assumptions create off-by-1000 bugs.
Is Date.now() the same across devices?
Close, within clock-sync error. Most devices sync via NTP within ~100 ms of real time. For events you want to compare across machines, server-side timestamps are authoritative — don't trust client clocks for anything that needs to order with other clients'.