Local-firstYour text never leaves your browser. No upload, no account, no server.
Most online text tools send whatever you paste to a server, run the work there, and send a result back. Your words sit in someone else's logs, backups and databases, and you have to trust a privacy policy.
Local-first means the opposite: the whole tool is downloaded to your browser and runs on your own device. Nothing you type is transmitted anywhere: not to us, not to anyone. There is no server that could receive it, which is a stronger guarantee than a promise not to look.
Three consequences worth knowing:
Paste a column of Unix timestamps and get readable UTC dates back, one per line, or go the other way and turn dates into epoch values. Seconds and milliseconds are told apart by magnitude, so a log that mixes both still converts correctly, and you can force either unit when you already know which you have. Lines that cannot be read are reported in place rather than silently dropped, so a column of a thousand values comes back the same length it went in.
Seconds and milliseconds in the same column
1516239022 1735689600000
1516239022 → 2018-01-18T01:30:22.000Z 1735689600000 → 2025-01-01T00:00:00.000Z
Unix time is defined as seconds since 1 January 1970. JavaScript, Java and most JSON APIs work in milliseconds since the same instant. The two look alike: both are just integers, and a value read in the wrong unit is out by a factor of a thousand.
The consequences are asymmetric. Reading milliseconds as seconds gives a date tens of thousands of years in the future, which is obviously wrong and gets caught. Reading seconds as milliseconds gives a date in January 1970, which looks like a null or a default and is often mistaken for missing data rather than a unit bug.
A ten-digit value is seconds and a thirteen-digit value is milliseconds for every date between 1973 and the year 5138, which covers everything anyone is realistically working with. That is the rule applied here, and the output shows which interpretation was used so you can check it.
Local time would depend on the machine reading the page, so two people looking at the same timestamp would see different answers and neither could tell which was intended. UTC is unambiguous.
It is also almost always what the source uses. Databases, log files and API responses store UTC by convention, and the timezone conversion belongs at the display layer of whatever consumes them: not in the middle of a debugging session.
Every line converts independently, so a column of a thousand values comes back as a column of a thousand results. Blank lines are preserved rather than collapsed, which keeps the output lined up with the column you pasted if you intend to paste it back.
Lines that cannot be interpreted are reported in place with the reason, not dropped. A silent drop would shift every subsequent row by one: the kind of error that is invisible in the output and obvious only after it has been pasted into a spreadsheet.
A ten-digit value is seconds and a thirteen-digit value is milliseconds, for any date between 1973 and the year 5138. That is the rule this tool applies automatically, and it tells you which it used. Unix time is defined in seconds; JavaScript, Java and most JSON APIs use milliseconds, which is where the confusion comes from.
Because a millisecond value was read as seconds, which divides the elapsed time by a thousand and lands you just after the epoch. Set the input unit to milliseconds explicitly and it will resolve correctly.
UTC, deliberately. A local-time result would depend on the machine reading it, so the same page would show different answers to two people looking at the same data. Logs and databases almost always store UTC, so this matches the source.
Yes. Paste as many lines as you like and each is converted independently. Blank lines are preserved so the output stays aligned with the column you pasted, which matters if you are pasting it back into a spreadsheet.