How do you convert a Unix timestamp to a human-readable date?
Paste it into a Unix timestamp converter. Read the result. That's the easy part.
The hard part is making sure the converter knows whether your timestamp is in seconds, milliseconds, microseconds, or nanoseconds. Guess wrong, and you get a wrong date with no warning.
Most converters silently treat every input as seconds. Fine for the 10-digit values you get from date +%s on the command line. Not fine the moment you paste a 13-digit value out of a JavaScript log, a Datadog trace, or a Kafka record. The tool reports a date in the year 56,210 — or sometimes a date in 1970 — and you sit there wondering why production looks like the Mesozoic.
Epochr fixes that one specific failure. Paste any timestamp and it tells you what unit it detected — seconds, milliseconds, microseconds, nanoseconds — *before* it shows you the converted date. The detection is visible, color-coded, and explained in a tooltip. You always know what you're looking at.
The rest of this post walks through the trap, the math, and what a converter ought to do.
What is the difference between a 10-digit and 13-digit Unix timestamp?
A 10-digit Unix timestamp is in seconds since January 1, 1970 UTC. A 13-digit Unix timestamp is in milliseconds since the same epoch. They look almost identical until you notice the three extra zeros at the end.
Same instant, both forms:
- Seconds (10 digits):
1714003200 - Milliseconds (13 digits):
1714003200000
Paste the millisecond value into a converter expecting seconds and the tool happily computes a date roughly 54,000 years in the future. Paste the seconds value into a converter expecting milliseconds and you get a date a few seconds after midnight on January 1, 1970. Neither result is your bug — but you're about to spend an hour treating it as one.
The defense is simple: count the digits before you trust the output. Or use a converter that counts for you and shows the unit on the screen.
How do you convert milliseconds to a date?
Divide by 1000 to get seconds, then convert. Or skip the math and let a converter that handles milliseconds natively do it for you.
In code:
const ms = 1714003200000;
const date = new Date(ms);
console.log(date.toISOString());
// 2024-04-25T00:00:00.000ZJavaScript's Date constructor expects milliseconds, so the language itself enforces the millisecond convention for web work. Python's datetime.fromtimestamp() expects seconds. Moving timestamps between a Node service and a Python service is the canonical source of off-by-1000 bugs, and it'll get you at least once before you wire up a linter rule for it.
Epochr handles this for you. Paste 1714003200000, see a green "milliseconds" badge, and the output panel fills with ISO 8601, UTC, local time, relative time ("a year ago"), day of the week, and date components — every one of them with a one-click copy button. No mental math.
What does a 13-digit Unix timestamp mean, and why does my converter show 1970?
A 13-digit timestamp is milliseconds since epoch. If your converter shows you a date near January 1, 1970, it's treating those milliseconds as seconds. The math goes wrong silently because both inputs are valid integers — there's no syntax error to surface, just a wrong date.
Here's the failure mode in detail. You paste 1714003200000. The converter doesn't divide, treats the value as seconds, and computes a date 54,316 years from now. Some tools notice the absurd magnitude and clamp the value back, landing you in 1970. Others happily render the year 56,310 with no warning. Both behaviors are wrong, and both leave you debugging a problem that was never in your code.
The fix is to make detection a first-class output. Show the unit. Explain the unit. Let the user override it when the heuristic is wrong. EpochConverter does conversion well but treats unit detection as an afterthought. CurrentMillis assumes milliseconds always. UnixEpoch.dev supports the units but doesn't surface its reasoning. Epochr leads with the badge — and the badge is the point.
How do you convert a Unix timestamp to ISO 8601?
ISO 8601 is the international standard for date and time formatting. The Unix timestamp 1714003200 becomes 2024-04-25T00:00:00.000Z in ISO 8601 form.
Most APIs, databases, and logs prefer ISO 8601 over raw epoch values because it's human-readable, sorts correctly as a string, and carries timezone information. Postgres timestamptz, MongoDB ISODate, JSON serialization in every web framework — they all default to ISO 8601 or a close relative.
Epochr's output panel puts ISO 8601 in the first row with a copy button that drops the formatted string straight into your clipboard. No "right-click, select all, copy" dance, no manual reformatting. Click, paste, move on.
What about microseconds and nanoseconds?
A 16-digit timestamp is microseconds (µs) since epoch. A 19-digit timestamp is nanoseconds (ns). Both show up in observability data — eBPF tracing emits nanoseconds, some Go and Rust services log in microseconds because that's what time.Now().UnixMicro() returns, and Prometheus mixes its own conventions on top.
Most converters don't handle these units at all. The ones that do require a manual unit picker, which means you have to know what you have before the tool can tell you what you have. Epochr detects all four units automatically by digit count and magnitude, and the badge color shifts so you can tell at a glance:
- 10 digits → seconds
- 13 digits → milliseconds
- 16 digits → microseconds
- 19 digits → nanoseconds
Edge cases exist. A timestamp from 1970 has fewer significant digits. Unit ambiguity is real for very small values. Epochr handles those by checking magnitude as well as digit count, and by letting you override the detection when you need to.
Why bother building another epoch converter?
The category is crowded. EpochConverter has held the top search result for over a decade. CurrentMillis has a developer cult following. UnixEpoch.dev is fast and minimal. No shortage of working tools.
The shortage is in tools that respect your time when you're debugging at 2 AM. Ad-heavy interfaces, no copy buttons, no unit detection, no dark mode, no tooltips explaining what the tool just did — these are the small frictions that compound when you're running on caffeine and trying to figure out why a webhook fired three hours after the event it was reporting.
Epochr is what we wanted EpochConverter to be in 2026: clean, fast, dark by default, every output one click from your clipboard, and a detection badge that tells you what your timestamp is *before* it tells you what it converts to. No accounts, no premium tier, no AI assistant lurking in the corner. Just a Unix timestamp converter that works.