UUID v4 जनरेटर

What the UUID v4 Generator does

This tool creates version 4 UUIDs — universally unique identifiers — one at a time or in bulk, up to a thousand at once. A UUID is a 128-bit value written as 32 hexadecimal digits in the familiar 8-4-4-4-12 grouping, for example f47ac10b-58cc-4372-a567-0e02b2c3d479. You reach for it whenever you need an identifier that you can mint anywhere, on any machine, without asking a central database "what number is next?" — primary keys created on the client before a row is saved, correlation IDs stitched across microservices and logs, idempotency keys for API requests, file and object names that must never collide, or message IDs in a queue. The options let you produce many at once, switch to uppercase, and strip the hyphens for contexts that want a compact 32-character string.

How version 4 UUIDs are made

Version 4 means "random". The generator asks the browser's cryptographic random source, crypto.getRandomValues(), for 16 random bytes, then stamps two small regions to make the value RFC 4122-compliant. Four bits in the seventh byte are overwritten to mark the version — that is why the third group of every v4 UUID always starts with the digit 4. Two bits in the ninth byte are set to 10 to mark the variant, which is why the fourth group always begins with 8, 9, a or b. Those six fixed bits are the only ones that are not random. That leaves 122 random bits, which is roughly 5.3 × 10³⁶ distinct values — an unfathomably large space.

• Layout — xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, where the 4 is the version and y is one of 8, 9, a or b.
• Randomness — 122 bits, sourced from the same cryptographic generator used for keys and tokens, not from Math.random().
• Collision odds — thanks to the birthday bound, you would need to generate on the order of a quintillion (about 2.7 × 10¹⁸) UUIDs before a single duplicate becomes even 50% likely.

When to use it, and what to watch for

A v4 UUID is the right choice when uniqueness and decentralised generation matter more than order. Its one real drawback is that it is deliberately random, so consecutive UUIDs are not sortable and, as a database primary key, they scatter inserts across an index instead of appending neatly — teams that care about index locality sometimes prefer a time-ordered scheme instead. Do not treat a UUID as a secret: it is unguessable in practice, but it is not an authentication token and should not gate access on its own. Remember that the hyphenated and hyphen-free forms represent the same value, and comparisons should be case-insensitive because 4372 hex is identical whether written in upper or lower case. If you are wiring identifiers through a service, the same UUIDs slot straight into requests you make against the s4m developer API.

Generated locally, never uploaded

Every UUID here is produced on your own device by JavaScript running in your browser; nothing is requested from a server and nothing is sent back. The identifiers are not logged, stored or transmitted to s4m or anyone else — there is no round-trip, so even generating a thousand at once creates zero network traffic. That means you can mint identifiers for private systems, internal tooling or unreleased projects with confidence that they exist only where you generated them. Check it yourself with the network tab open, or offline: the generator relies solely on your browser's own cryptographic random source and keeps working with no connection at all.