UUID v4, time-sortable UUID v7, and nanoid — one at a time or a thousand at once.
This runs entirely in your browser. Nothing you paste, type or drop here is sent anywhere — there is no server on the other end of it.
Identifiers you can generate without asking a server: UUID v4, UUID v7, nanoid and a short id, one at a time or a thousand at once. The interesting choice is not which library to use — it is v4 versus v7, and that choice shows up later as database performance rather than as anything you notice on the day.
v7, in most cases. Random v4 keys scatter inserts across the whole index, which fragments pages and hurts write throughput and cache locality as a table grows. v7 is time-ordered, so new rows append. Choose v4 only when it genuinely matters that the id reveals nothing about when the record was made.
They come from the browser's cryptographic random source, so a v4 UUID is unguessable in practice. Even so, an id is an identifier and not an authorisation — treat 'knows the URL' as public, not as permission.
Theoretically yes, practically no. With 122 random bits you would need to generate billions per second for decades before a collision became likely. Time-ordered v7 narrows the random space per millisecond but leaves far more than enough.
No. Everything happens in your browser and nothing is transmitted, which also means you can generate ids on this page with no network connection at all.