Generate UUID v4, time-sortable UUID v7 or Nano IDs in bulk, from your browser's own cryptographic random source.
GeneratingFor database keys. A v7 carries its creation time in the leading bits, so a column of them sorts chronologically and new rows land at the end of the index instead of scattering across it, which is what makes v4 primary keys expensive at scale.
Yes. Every value comes from crypto.getRandomValues, the same cryptographic source your runtime uses, and v4 is generated by the browser's own crypto.randomUUID. Nothing here is seeded from the clock alone or from Math.random.
Shorter identifiers meant for URLs: 21 characters from a 64 character alphabet, with roughly the collision resistance of a UUID. Use them where a value will be read aloud, typed, or pasted into a link.
In theory yes, in practice no. A v4 has 122 random bits, so you would need to generate billions a second for a century before a collision became likely. The realistic risk is a bad random source, not the maths.
In a native uuid column where the database has one, which is 16 bytes rather than the 36 characters of the text form. Postgres, MySQL and SQL Server all have it. If you must use text, at least make it a fixed-length column and keep the case consistent.