Convert Unix timestamps to readable dates online

A Unix timestamp is easy to store and annoying to read. You see 1716403200 in a webhook payload, a database row, or a log line, and now you have to answer a simple question: what time did this actually happen?

When you convert Unix timestamps to readable dates online, the useful part is not the conversion itself. Any runtime can do that. The useful part is checking seconds versus milliseconds, confirming the time zone, and making sure you are not misreading an incident timeline by a few hours.

What a Unix timestamp represents

A Unix timestamp counts time from 00:00:00 UTC on January 1, 1970. Most backend APIs use seconds. Many JavaScript systems use milliseconds because Date.now() returns milliseconds.

That difference is where a lot of debugging mistakes start:

Date.now();
// 1716403200000, milliseconds

Math.floor(Date.now() / 1000);
// 1716403200, seconds

Both values point to the same moment. They are just different units. If you paste a millisecond timestamp into a converter that expects seconds, you will get a date thousands of years in the future. If you paste a second timestamp into code that expects milliseconds, you will land in January 1970.

Seconds or milliseconds? Check the length first

A quick length check catches most timestamp mistakes before you chase the wrong bug.

Current Unix timestamps in seconds are usually 10 digits. Millisecond timestamps are usually 13 digits. Microseconds and nanoseconds are longer, and they often show up in analytics pipelines, traces, or database internals.

1716403200       seconds
1716403200000    milliseconds
1716403200000000 microseconds

Do not rely on length forever. It is a debugging shortcut, not a formal parser. But when you are staring at a production log, the digit count is often enough to tell whether the value came from a backend service, browser code, or a database driver.

Toolblip's Unix Timestamp Converter is handy for this because you can paste either shape and compare the result in local time and UTC without sending the value through a server.

UTC is the source of truth

Timestamps do not store a time zone. They represent one instant in UTC. The readable date changes only when you choose how to display that instant.

That matters during incident review. A cron job might log a timestamp in UTC, your database UI might display local time, and a teammate might paste a date from their own time zone. Everyone can be looking at the same event and still disagree about the hour.

For debugging, write down both forms:

Unix timestamp: 1716403200
UTC: 2024-05-22 16:00:00 UTC
Local: 2024-05-22 12:00:00 America/New_York

Now the team can talk about the event without silently switching reference frames.

Convert timestamps from the terminal when needed

A browser converter is fastest for quick checks, but the terminal is useful when you need repeatable evidence in a runbook or incident note.

On macOS and Linux, Python is the most portable option:

python3 - <<'PY'
from datetime import datetime, timezone
value = 1716403200
print(datetime.fromtimestamp(value, tz=timezone.utc).isoformat())
PY

For milliseconds, divide by 1000 first:

python3 - <<'PY'
from datetime import datetime, timezone
value = 1716403200000
print(datetime.fromtimestamp(value / 1000, tz=timezone.utc).isoformat())
PY

If the output does not match what your app shows, check whether the app is applying a user profile time zone, browser time zone, or database session time zone after conversion.

Where developers usually get timestamps wrong

The most common mistake is mixing units between services. A Node app sends milliseconds, a Laravel API expects seconds, and the database stores whatever arrived. The value looks valid, so validation passes, but the scheduled action fires at the wrong time.

The second mistake is treating a date string and a timestamp as interchangeable. 2026-05-22 means a calendar day. A timestamp means a precise instant. If your API accepts both, document which time zone applies to date-only input.

The third mistake is comparing a local date against a UTC timestamp during daylight saving changes. This is how reports end up off by one hour or one day around the edge of a month.

A safer timestamp debugging habit

When a timestamp looks suspicious, do four checks before changing code:

1. Count the digits to identify seconds or milliseconds.
2. Convert the value to UTC first.
3. Convert the same value to the relevant local time zone.
4. Compare it with one nearby event from logs, not just the user-facing time.

If you also need to inspect encoded payloads while debugging APIs, use a local browser tool for that too. Toolblip has a URL Encode/Decode tool for query strings and callback URLs, and the same privacy rule applies: use harmless samples when the value might contain secrets.

Readable dates are only useful if they preserve the exact moment behind the number. Convert the timestamp, check the unit, write down the time zone, and then decide whether the bug is in the data or just in how you were reading it.