I pasted 1650000000000 into JavaScript's Date in this sitting. It printed 15 April 2022, 05:20 UTC.
The same digits, read as microseconds, printed 20 January 1970, 02:20 UTC. Seconds of 1650000000 is the 2022 instant again. The number did not change. The unit did.
That is the whole job. A Unix time is a count from 1970. The page that prints a date has to say which count it used. If it guesses in silence, you get January 1970 and you trust it, because the page looks sure.
The new page is Epoch Timestamp Converter. You paste a number. It counts the digits. It names the unit. Then it prints UTC, a city you pick, ISO, and Discord tags. The number stays in the tab.
Thirteen digits, one date
1650000000000 has 13 digits. In this sitting that is milliseconds since 1970, and milliseconds of that size land on 15 April 2022. I did not pick that number for poetry. It is the sample on the page, and Date in this tab agrees.
A converter that treats 13 digits as seconds walks off the calendar we use. Thirteen digit seconds of that paste is the year 54289. This page will not print that. It caps UTC years at 1 to 9999, which is the range Intl will format without lying, and it tells you the year is outside that range.
A converter that treats 13 digits as microseconds walks the other way. 1650000000000 microseconds is 1,650,000,000 milliseconds, which is 20 January 1970, 02:20 UTC. That is the usual miss. The page looks fine. The date is wrong.
I ran both readings in this sitting. Milliseconds: 2022-04-15T05:20:00.000Z. Microseconds: 1970-01-20T02:20:00.000Z. Same paste.
Count the digits out loud
The rule this tab uses is magnitude, not a hidden heuristic.
| Digits | This tab treats it as |
|---|---|
| 10 or fewer | seconds |
| 13 | milliseconds |
| 16 | microseconds |
| 19 | nanoseconds |
Zero is seconds. It prints 1970-01-01T00:00:00.000Z. A negative second prints 31 December 1969. I checked both in this sitting.
The line under the paste is the assumption, spoken: "This looks like milliseconds (13 digits)." You can still pick Seconds, Milliseconds, Microseconds, or Nanoseconds. Auto is the default. The override is one click.
This looks like milliseconds (13 digits).
That sentence is the product. A date without it is a guess you cannot audit.
Eleven digits sit and wait
Eleven or twelve digits could be seconds into the far future or milliseconds near 1970. Fourteen or fifteen could be milliseconds or microseconds. Seventeen or eighteen could be microseconds or nanoseconds.
This tab does not pick for you. It prints the digit count and the two candidates, and it waits. The buttons say Use seconds and Use milliseconds, or whichever pair the count allows.
I pasted 10000000000, eleven digits, in this sitting. The page did not invent a date. It asked.
Guess in silence and you get a date nobody meant. Waiting is slower for one second. It is cheaper than a wrong year.
Seconds of the same paste
The sample button fills 1650000000000. Auto reads milliseconds. Force Seconds on that paste and the year is 54289, which this tab refuses.
If you actually have seconds, paste 1650000000. Ten digits. Auto reads seconds. UTC is 15 April 2022, 05:20 again. Discord tags use that seconds value. Milliseconds of the same instant is 1650000000000. The page prints both, so you can copy the one the other system wants.
You can also paste an ISO instant with a Z. That is UTC. A wall clock without a Z uses the zone picker. I checked 2022-04-15T05:20:00.000Z in this sitting. It is the same instant as the 13 digit sample.
Zero and minus one
Paste 0. Auto reads seconds, because one digit is ten or fewer. UTC is 1970-01-01T00:00:00.000Z. That is Unix epoch, on purpose. If a log printed 0 because a field was missing, the date is still 1970. This tab will not hide that.
Paste -1. That is one second before epoch. UTC is 1969-12-31T23:59:59.000Z. I checked that in this sitting. Negative timestamps show up in tests. They also show up when a signed 32-bit time overflowed the other way.
A page that clamps negatives to 0 has invented a date. This one keeps the sign.
Years this tab will not print
JavaScript's Date can hold milliseconds far outside a calendar year you can read. The ECMAScript time value limit is 100 million days either side of 1970, which is 8.64e15 milliseconds. Thirteen digit seconds of 1650000000000 is 1.65e15 milliseconds. That is inside the Date limit and still the year 54289.
I hit that in this sitting when I forced Seconds on the sample. The first version of the converter said ok, because it only checked the Date limit. A date in year 54289 is not useful on this page. The cap is UTC years 1 to 9999. Outside that, the page names the range and stops.
Sixteen digit microseconds and nineteen digit nanoseconds of a real instant still fit. Nanoseconds are divided by 1e6, microseconds by 1000, so the instant you get is millisecond precision. The extra digits do not come back on the way out. The page prints milliseconds next to the assumption. It does not pretend it kept nanoseconds.
UTC and a city you pick
Unix time is UTC. The zone list is wall clock. The default is UTC, not whatever the laptop thinks it is, because a log line from a server is UTC until you say otherwise.
Pick America/New_York and 1650000000000 prints 15 April 2022, 01:20, GMT-04:00. That offset is daylight time for that date. I printed it in this sitting with Intl.DateTimeFormat and timeZone set to America/New_York.
The list is whatever IANA names this browser already knows. There is no extra timezone pack. I did not add @js-temporal/polyfill. Intl with a timeZone option was enough for the DST cases below. A polyfill for a claim is how a page gets heavy for nothing.
ISO is always the UTC instant with a Z. Copy ISO if you want a string another program will parse. Copy the city line if you want to read it.
The hour that never happens
On 8 March 2026, clocks in America/New_York jump from 02:00 to 03:00. 02:30 that morning never happens.
I typed 2026-03-08 02:30:00 with the zone on America/New_York. This tab said that hour does not exist. 01:30 that morning maps to 2026-03-08T06:30:00.000Z. 03:30 maps to 2026-03-08T07:30:00.000Z. Those two I checked in this sitting against the zone data in the browser.
A page that picks the next valid instant without telling you has moved your meeting. This one stops.
The hour that happens twice
On 1 November 2026, 01:30 happens twice in America/New_York. The clocks fall back from 02:00 to 01:00.
I typed 2026-11-01 01:30:00 in that zone. This tab returned both instants: 2026-11-01T05:30:00.000Z and 2026-11-01T06:30:00.000Z. The buttons say Earlier and Later. You pick.
A page that keeps only one of those has thrown away an hour of logs. The later one is not "more correct." It is the other time 01:30 happened.
A column from a log
One box is fine for a JWT exp claim. The usual paste is a column. Bulk column takes one timestamp per line, names the unit on each row, and prints UTC plus the city.
I ran two lines in this sitting: 1650000000 and 1650000000000. The table named seconds on the first row and milliseconds on the second. Both UTC values were 15 April 2022, 05:20.
Download is a TSV. The headers are input, unit, utc, zoned, iso. Empty lines stay, so the rows still line up with the file you copied. The cap is 500 lines. A bigger dump belongs in CSV Viewer and Editor, where you can hide columns and replace in place. This page will not pretend a million row paste is a good idea in a text box.
Discord tags are seconds
Discord renders a tag like <t:1650000000:F> as a date in each reader's clock. The number inside is seconds, even if you pasted milliseconds.
This panel copies every public style. The preview next to the tag is this tab's stand-in, so you can see Friday, April 15, 2022 5:20 AM before you send it. Relative is R. Discord writes the "3 hours ago" bit when the message shows. The stand-in here is a date, not a live countdown.
| Style | What Discord draws |
|---|---|
| F | long date and time |
| f | short date and time |
| D | long date |
| d | short date |
| T | long time |
| t | short time |
| R | relative |
Copy F if you want the long line. Copy R if you want "in three hours" on the other person's screen. Do not paste milliseconds into that tag. Discord will read a date in 2022 as a date in 54289, or it will look broken. This panel always writes seconds.
The live clock
The top of the page is now. Seconds and milliseconds, UTC, and the city you picked, ticking once a second after the tab hydrates.
That clock is for checking the page, not for proving a server's time. It uses Date.now() in this browser. If the laptop clock is wrong, the live row is wrong. The paste still converts from the number you typed.
Unix epoch 0 is 1970-01-01T00:00:00.000Z. If you paste 0 and you wanted "now," you pasted the wrong box. The live row is the now.
Settings, a link, a preview
The unit and the time zone live in this browser under softery.epoch-timestamp-converter.settings. The paste is not stored. Clear settings puts Auto and UTC back. Clear paste empties the boxes and leaves the knobs.
Copy link puts the number, the unit, and the zone in the URL, because that is the job. A log column does not go in the URL. You see the preview before it is copied: the timestamp, the unit name, the zone name. If you do not want that number in a shared link, do not copy the link. Download the TSV instead.
A settings URL is useful when the card is a public instant. It is a bad idea for a private log. The preview is there so you can tell which one you are about to send.
Download on a single result writes epoch-timestamp.txt with the assumption, UTC, the city line, ISO, seconds, milliseconds, and microseconds, each on its own line, tab separated. Open it in a text editor. If the file does not contain the ISO you saw on screen, the download failed. A blob URL that never clicks is a common miss. This page uses a real download attribute.
Bulk download is epoch-column.tsv. Same rule. Open it. The first row is the header.
What Mixpanel sees
Mixpanel and Google Analytics load with the rest of Softery.io. They see that someone opened the tool. They get the unit name, the zone name, a size bucket on a bulk paste, and whether a copy or a download happened. They do not get the number.
The Mixpanel slug is epoch-timestamp-converter. That is the URL slug. Setting names go out as milliseconds, seconds, Auto, UTC, America/New_York. Sizes go out as buckets. The paste does not.
If you came here because a privacy page promised zero third-party scripts, that is not this site. I will not write that sentence. After the page has loaded you can unplug the cable and still go from 1650000000000 to a date. The math is JavaScript here. The telemetry is the site, not the paste.
Nearby tools
Sunrise, sunset, and a year of daylight in a zone you pick belong on Sunrise and Sunset Times. A pasted table with more than a timestamp column belongs on CSV Viewer and Editor. Both stay in the tab.
Epoch Timestamp Converter is the thirty-ninth free tool on the hub. It runs after the JavaScript has loaded. Unplug the cable if you want. The number is still in the tab.
- Open Epoch Timestamp Converter.
- Hit Use the sample, or paste 1650000000000.
- Read milliseconds, then 15 April 2022, 05:20 UTC.
- Copy a Discord tag, or download the TSV if you pasted a column.
Last updated: September 17, 2026 | Reading time: 10 minutes
Written by Softery.io, after a 13 digit paste printed a date in 1970.