Unix Timestamp Converter

Paste an epoch number like 1753104189 and it lays out every common way of writing that instant at once, not the single date string most converters stop at. Relative time comes first, so 3 hours ago or in 5 days tells you where the number sits with no arithmetic. Below that sit ISO 8601 in UTC and in your own zone with the offset, RFC 2822 the way an email or HTTP header wants it, the plain UTC and local readouts, and both epoch units, seconds and milliseconds. Every row has its own copy button. Grab the format your code actually needs and move on. The whole thing runs in your browser, and the only thing that leaves the machine is what you put in a share link yourself: the timestamp you were converting.

1. Decode a number. Drop a timestamp into the Timestamp to date box. It reads seconds versus milliseconds off the digit count, then fills the panel with relative time, ISO 8601, RFC 2822, UTC, local, and both epoch units.
2. Copy the one you need. Every row has its own Copy button, so if your API wants ISO 8601 and your log wants epoch seconds, you take each straight from its row without reformatting anything by hand.
3. Go the other direction. Set a day and time in the Date to timestamp picker. The same full panel comes back, so you get epoch seconds and milliseconds plus the ISO and RFC strings for that exact moment.
4. Hit Use now beside the picker to prefill this instant, then nudge the date or time from there.
5. The live count up top ticks the current Unix time every second, a reference number sitting right there to compare against.
6. Share it. The Share button copies a link that reopens with your input already converted, which is handy for dropping into a ticket or a chat so a teammate sees the same breakdown you did.

The format you need out of a raw epoch is never the one a basic converter hands you. It shows a GMT string when the API wanted ISO 8601, or local time when a mail header needed the +0000 RFC 2822 shape. So you copy the date into a second tool, reformat, and lose two minutes on a thing that should cost none. This panel prints all of them off the one number, and you copy the exact string you were after.

A quick map of what to reach for. ISO 8601 is the one you want inside JSON, a database, or almost any API, because it sorts correctly as plain text and every language ships a parser for it. RFC 2822 is the older email and HTTP shape, Tue, 21 Jul 2026 14:03:09 +0000, still what a Date: header or an RSS feed expects. The relative row, 3 hours ago or in 5 days, is for people, and it doubles as the quickest expiry check you have: paste a token's exp claim, and if the row reads a time in the past, that token is already dead. UTC and local are the readable forms for eyeballing a value, and the two epoch units are there because whatever you are feeding speaks one of them.

Most epoch bugs come from the unit, not the value. Classic Unix time counts whole seconds. Plenty of modern platforms count milliseconds instead, and JavaScript is the loud one, Date.now() and new Date(n) both work in milliseconds while most databases, APIs, and Unix tools work in seconds. Feed a seconds number to something reading milliseconds and your date lands a few weeks after January 1970. Do the reverse and you get a year in the tens of thousands. The tell is the length of the number, so the converter counts digits for you. Thirteen digits or more and it reads the value as milliseconds, and anything shorter it reads as seconds. That guess is right nearly every time, and on the rare miss the date it shows makes the mismatch plain on sight.

Value	Digits	Unit
1783238400	10	seconds
1783238400000	13	milliseconds
1783238400000000	16	microseconds
1783238400000000000	19	nanoseconds

All four rows are the same instant with more zeros stacked on. Seconds and milliseconds get read automatically. Microsecond and nanosecond values (the sixteen and nineteen digit ones out of Postgres or Go's UnixNano) are rarer, and if you land one, trim it to milliseconds first.

JavaScript trips people on this daily. Call new Date(1700000000) and you get a date less than three weeks past the epoch, because the language read 1.7 billion as milliseconds. What you meant was new Date(1700000000 * 1000), which gives you November 2023. The mistake runs both ways, and either way the digit count is what gives it away.

A Unix timestamp is one absolute instant anchored to UTC, with no zone baked in. The zone only shows up when you format the number for a human. So 1783238400 has no single wall-clock answer until you say where. That value is 08:00 UTC on 5 July 2026, which is the same moment as 09:00 in London on summer time and 13:45 in Kathmandu.

That is why the panel prints UTC and your local time next to each other. A value that looks wrong is usually just being read in a different zone than the one it was made in, and seeing both together settles it in a second instead of costing you an afternoon. The picker runs the other way, it takes whatever you enter as your computer's local time and converts that to the universal number, which is what you want when you turn "today at 5pm my time" into something to store.

One rule falls out of all this, and it is worth keeping. Store the timestamp, not a local wall-clock string. An instant always refers to the same point in time. Store a local "2:30pm" instead and its meaning shifts the moment daylight saving flips or the user moves to another zone.