You need a primary key that will not collide when two laptops insert offline. UuidShift generates UUID v4 identifiers in the browser with a CSPRNG, instantly, no signup, no 'UUID as a service.' Use it for test fixtures, client-side IDs, and request correlation strings. Do not use it as a security token with meaning, as a sort-friendly time sequence (that is UUID v1/v7 territory), or as a proof that a row is authentic. v4 is random. Random is enough for uniqueness at human scale. It is not a signature. Do not skip unique constraints in the database just because v4 collisions are rare at human scale.
Click, copy, paste into JSON. Bulk generate a handful if you are writing fixtures. Format is 8-4-4-4-12 hex with version 4 in the right nybble. If a parser wants no hyphens, strip them; the bytes are the same. Uppercase vs lowercase hex should not matter to a spec-compliant consumer, but some databases are rude.
When not to use it: you needed ULID or UUID v7 for time-ordered indexes, or you needed a sequential integer for a public invoice number. Random UUIDs as invoice IDs are ugly and leak nothing useful, which is sometimes what you want. Also skip it if you were about to use a UUID as a session secret without additional entropy practices — treat session tokens as tokens, not as database IDs.
Privacy is total: generated locally. There is no registry of UUIDs we issued. Collision with another v4 generator is not a practical worry for a few million IDs. If you generate a billion a second, read the math elsewhere. You are not doing that in this tab. Strip hyphens only when a parser forbids them; the bytes are the same either way.
A test suite needs 20 order IDs. You generate 20 v4 UUIDs, paste into a JSON fixture. All version nybbles are 4. The app accepts them as PK values. A colleague used a timestamp string instead and collided in CI; you did not. Nothing called home to a UUID API. You did not use the IDs as API keys. Twenty fixture IDs that all show version nybble 4 is the test-suite win, not a UUID-as-a-service call.
UuidShift generates v4 UUIDs in the browser. There is no server-side registry and no upload. The identifier is only as sensitive as where you paste it. Close the tab; there is nothing to retain. There is no registry of identifiers we issued; close the tab, there is nothing to retain on a server.
Full policy: Shift Privacy Policy. Questions: [email protected].
Not as a practical event for normal volumes. v4 is 122 bits of random. Do not use that sentence as a reason to skip unique constraints in the database. A few million v4 IDs are fine; still put a unique constraint in the database because computers are cheap.
v1 can leak MAC-ish time stories and is not what this generator is. v4 is the boring default for IDs that should not encode time. v1 can leak MAC-ish time stories; v4 is the boring default for IDs that should not encode a clock.
You can put random bytes in a key, but an API key is a secret with rotation and hashing on the server. A pasted UUID in a public repo is a leak. Different job.
RFC 4122 is case-insensitive. Some systems normalize to lowercase. Pick one in a codebase and stop arguing in PRs. RFC 4122 is case-insensitive; pick lowercase in a codebase and stop arguing about it in review.
Related tools: HashShift · PassShift · JsonShift
Guides · All Shift tools · About · Contact