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:
Generate as many UUIDs as you need, either random v4 values or time-ordered v7 ones, using your browser's cryptographically secure random source rather than Math.random. Switch to Inspect and paste UUIDs you already have to read back their version, variant and, for v7, the moment they were created. Nothing is requested from a server, so the values are yours alone and no log anywhere records what was issued.
Inspecting a v7 recovers when it was made
0198a1c2-3d4e-7f80-9abc-def012345678
v7 — time-ordered, random tail, variant RFC 4122 created 2026-08-05T12:00:00.000Z
A v4 UUID is 122 random bits. A v7 UUID replaces the leading 48 with a millisecond timestamp, so values generated later always sort after values generated earlier.
That ordering is the whole point, and it matters most as a database primary key. Random values scatter across a B-tree index, so consecutive inserts land on different pages, the index fragments, and write throughput degrades as the table grows. Time-ordered values append near each other and the index stays compact.
The trade is that a v7 leaks its creation time to anyone holding it. If the identifier is public and the timing is sensitive (when an account was created, when a document was drafted) stay with v4.
A v4 UUID is generated from a cryptographically secure source, so guessing one is not realistic. But UUIDs are designed to be unique, not secret: they end up in URLs, logs, analytics events and error reports, and any of those can leak one.
Treat a UUID as an identifier that happens to be hard to guess, not as an authentication token. A password reset link or a session identifier should use a purpose-made secret that is never logged and can be revoked, because a UUID in a URL will be recorded somewhere you did not intend.
These are generated with crypto.getRandomValues, the browser's cryptographically secure generator. Math.random is not one: it is fast and statistically reasonable, and in several engines its future output can be reconstructed from a handful of prior values.
A generator built on Math.random still produces UUIDs that look correct and pass a format check: the failure is invisible until someone predicts the next one. That is why the distinction is worth caring about even though both approaches produce the same shape of string.
Use v4 unless the UUID is a database primary key. Random v4 values scatter across a B-tree index so every insert touches a different page, which fragments the index and slows writes at scale. Time-ordered v7 values sort by creation time, so inserts land together. If the value is a public identifier where ordering would leak information, stay with v4.
A v4 UUID carries 122 bits of randomness from a cryptographically secure source, which is enough to be unguessable. But a UUID is designed to be unique, not secret: it is often logged, put in URLs and shared. For a session token or password reset link, generate a dedicated secret instead.
For v4, the chance is negligible: you would need to generate billions per second for many years before a collision became likely. That is what 122 random bits buys. The real risk is not collision but a weak random source, which is why this uses crypto.getRandomValues rather than Math.random.
Inspect mode reads the version digit and the variant bits, and for v7 recovers the creation timestamp from the leading 48 bits. A v1 UUID historically embedded the generating machine's MAC address, which is why it fell out of favour for anything public.