What a UUID v4 actually is
A version-4 UUID is 122 random bits dressed in a standard costume: 32 hex digits grouped 8-4-4-4-12, with the version nibble fixed to 4 and the variant bits set in the fourth group. This generator uses crypto.randomUUID() where available (the browser's native, spec-compliant implementation) falling back to crypto.getRandomValues() with the version and variant bits set by hand. Either way the randomness is cryptographic, not Math.random().
Do you need to worry about collisions?
No. With 2122 possible values, you would need to generate about a billion UUIDs per second for roughly 85 years to reach a 50% chance of a single collision. If two "random" UUIDs ever collide in your infrastructure, the cause is a cloned VM image or a seeded PRNG, not probability.
Where UUIDs earn their keep
Distributed systems, mainly: any place where multiple nodes must mint identifiers without coordinating, request IDs for tracing a call across microservices, resource IDs created client-side before the database sees them, idempotency keys, correlation IDs in log pipelines. They also avoid the information leak of sequential integers, where /invoice/10452 quietly tells competitors your monthly volume.
The database indexing caveat
Fully random UUIDs make miserable clustered primary keys: every insert lands at a random point in the B-tree, causing page splits and cache churn that get worse as tables grow. If you need UUID keys at scale, look at UUIDv7, which front-loads a timestamp so values are roughly sorted by creation time; you keep the decentralised generation and lose most of the index pain. For small tables and non-key columns, v4 everywhere is perfectly fine.