Unix Timestamp and Epoch Converter

How to Tell Whether Your Timestamp Is in Seconds or Milliseconds

One of the most common timestamp mistakes is mixing Unix seconds with Unix milliseconds. A 10-digit value such as 1700000000 is usually seconds, while a 13-digit value such as 1700000000000 is usually milliseconds. If you paste milliseconds into a tool that expects seconds, the date may jump far into the future. If you paste seconds into a tool that expects milliseconds, the result may fall near 1970. This page helps you sanity-check the unit quickly before you trust the converted date in a log review, API test, or database export.

How to Compare Epoch Results with UTC and Local Time

Epoch time itself is timezone-neutral. The confusion happens when a human-readable value is displayed in UTC on one screen and in local time on another. If you are comparing application logs, cloud dashboards, browser timestamps, and database records, check whether each system is showing UTC, browser-local time, or a server-local timezone. A mismatch there can make two correct timestamps look inconsistent even when they represent the same instant.

Example Conversions You Can Verify Manually

Use known values when you want to confirm that a pipeline, script, or pasted value is behaving as expected. For example, 0 maps to 1970-01-01T00:00:00Z, and a modern 10-digit timestamp should normally land in a contemporary calendar year rather than the far past or far future. Simple checks like that help catch unit mistakes and bad assumptions before they spread into monitoring alerts, test fixtures, or analytics event debugging.

Common Timestamp Mistakes in APIs, Logs, and Databases

Real-world timestamp problems are usually not about the conversion formula itself. They come from copied decimal values, milliseconds being mistaken for seconds, timestamps stored as strings with surrounding whitespace, log viewers showing local time while APIs return UTC, or different systems rounding differently. This converter is useful because it lets you test the raw value directly and isolate whether the problem is in the timestamp, the source system, or the way the result is being displayed elsewhere.

When a Converted Date Looks Wrong

If the output looks wrong, check the timestamp length first, then verify whether the original source documented UTC or local time expectations. Next confirm that the pasted value is purely numeric and does not contain hidden spaces, decimal separators, or formatting copied from another interface. If you are converting from a human date back to epoch, remember that browser date inputs may reflect local timezone context rather than a literal UTC string unless you account for that in the surrounding workflow.

Privacy and Offline Use

All conversion happens locally in your browser. ToolMill does not need to send your timestamps, dates, incident references, or internal event data to a remote conversion service. That makes this page practical when you are checking production-like values, debugging internal logs, or verifying data exported from another system while keeping the raw values in your own browser session.