Timestamp Converter
Convert any Unix timestamp to UTC, local time and ISO 8601, with batch and timezone views.
This timestamp converter turns any Unix timestamp into UTC, your local time, ISO 8601, RFC 2822 and SQL, then lines the same instant up across a handful of timezones. Paste a 10 digit number, a 13 digit one, or a readable date and it auto detects whether you handed it seconds, milliseconds, micro or nano, so you stop reading one as the other. It is built for the messy moments: log debugging, JWT exp and iat claims, schedulers, backups and the odd database row. Drop a batch of mixed log lines in and it dumps clean CSV you can paste straight into a ticket. Unix time sits on UTC, so picking a timezone only changes how the moment reads, never the moment itself. Everything runs in your browser, so nothing you paste ever leaves the page.
100% in your browser. Nothing you type ever leaves this page.
Unix timestamp, ISO date, timezone and batch converter
Paste a Unix number (seconds, milliseconds, micro, whatever) or a readable date, and get back UTC, your local time, ISO 8601, RFC 2822, SQL, plus the same instant across a few timezones. It also chews through a batch of log lines and pulls apart JWT date claims. Mostly it exists so you stop reading a 10-digit number as seconds when it was milliseconds all along. Been there.
Everything runs in your browser. And remember: Unix time sits on UTC. Picking a timezone just changes how it reads, not the actual moment.
Timestamp conversion is really just guessing the unit right
A Unix timestamp converter saves you from the one mistake everyone makes: reading the number in the wrong unit. Unix timestamps look harmless because they are just numbers, and that is exactly why they bite. Some systems hand you seconds, JavaScript gives milliseconds, a database might be sitting on microseconds, and some event pipeline somewhere is logging nanoseconds because why not. A 10-digit value and a 13-digit value can be the same instant, if one is seconds and the other is milliseconds. Read it in the wrong unit and your date jumps by decades. This tool sniffs out the common digit lengths on its own, but you can also force seconds, milliseconds, micro or nano when you already know.
How to read timestamps safely
Figure out the unit first. For modern dates, Unix seconds usually land at 10 digits and milliseconds at 13. Micro and nano are longer, and they are honestly more precision than a plain JavaScript date wants, so the date you see here leans on the millisecond part. After that, keep storage and display in separate boxes. Store UTC instants. Format them for the human right at the edge, where you show them. And whenever an actual deadline or someone's calendar is on the line, say the timezone out loud.
- Unix seconds show up in JWT
exp,nbfandiatclaims. - Unix milliseconds are the JavaScript default, so you will see them in browser logs and plenty of APIs.
- ISO 8601 is usually the least painful format to hand between systems.
- Timezone views tell you what one instant actually means in Paris versus UTC versus Tokyo.
- Batch conversion earns its keep mid-incident, when the logs are a soup of mixed formats.
Common timestamp debugging examples
Token dies the second it is issued? Decode the JWT and run the exp claim as Unix seconds, you probably fed it milliseconds. Cron firing at a weird hour? Line up the server's timezone against the human one before you touch anything. A log date stuck in 1970 or sitting way out in the future almost always means seconds and milliseconds got swapped somewhere. And when two regions cannot agree on a date, do not go rewriting application logic yet. Compare the exact same UTC instant in both zones first. Nine times out of ten the data was fine and the display lied.
Frequently asked questions
Is Unix time affected by timezone?
Nope. It counts from the UTC epoch, full stop. Timezones only change how that instant gets dressed up for a human to read. The number underneath does not move.
Why do JavaScript timestamps have 13 digits?
Because Date in JavaScript counts milliseconds since the epoch, not seconds. Plenty of APIs use seconds though, and that mismatch is exactly where the off-by-1000 bugs sneak in.
How do I convert a Unix timestamp to a date?
Drop the epoch number in the box up top. It guesses the unit (seconds, milliseconds, micro, nano) and spits back your local time alongside UTC and a clean ISO 8601 string. If the guess looks off, force the unit with the dropdown and convert again.
What is the year 2038 problem?
Anything still cramming Unix time into a signed 32-bit integer runs out of room on 19 January 2038 and wraps around to a negative date, which looks like 1901. The fix is boring and already done in most places: use a 64-bit value. Modern languages and databases default to that now. The stragglers tend to be old embedded gear nobody wants to touch.