UUID v4 generator

UUID v4 generator is a free tool that creates a version 4 Universally Unique Identifier for use as a record, object or request identifier.

How does the UUID v4 generator handle my data?

The generation work takes place on the server. The input travels to the server over HTTPS, and the input is not stored. This means it would be inaccurate to say that generation happens entirely in your browser or that data never leaves your device.

A UUID v4 does not require personal text, a name or a password as its source. It is generated as an identifier rather than calculated from information you provide. Avoid attaching confidential meaning to the resulting value, since anyone who can see it can copy and reuse it.

What is a UUID v4?

A UUID v4 is a 128-bit identifier whose variable portion is generated randomly or pseudo-randomly, with several bits reserved to mark the UUID version and variant. It is commonly used when separate systems need to create identifiers without first asking a central service for the next available number.

The standard written form contains 32 hexadecimal characters split into five groups by hyphens. It follows the pattern 8-4-4-4-12 and is 36 characters long when the four hyphens are included.

A syntactically valid example is 550e8400-e29b-41d4-a716-446655440000. In a version 4 UUID, the first character of the third group is 4. The two most significant bits that identify the variant are 10, producing a leading hexadecimal character of 8, 9, a or b in the fourth group.

The value is an identifier, not encoded information. You cannot decode it to recover a creation date, account name, machine address or sequence number.

Which UUID version should I choose?

Choose version 4 when you need an independently generated, opaque identifier and do not need the same input to produce the same result. In one line, v1 uses time and node information, v2 is the DCE Security form, v3 derives a UUID from a namespace and name using MD5, v4 is random, v5 derives one using SHA-1, v6 reorders time-based data, v7 combines a Unix timestamp with random data, and v8 is intended for experimental or vendor-specific formats.

• Use UUID v4 for record IDs, upload references, API request IDs and test fixtures where randomly distributed identifiers are suitable.
• Use UUID v5 when a particular namespace and name must always produce the same identifier. It is useful for repeatable imports and deduplication rules.
• Consider UUID v7 when records need identifiers that broadly follow creation time and your database or software supports it.
• Use a normal sequential integer when values are created by one database and compact, naturally ordered keys matter more than decentralised generation.

Older versions remain in existing systems, but a new design should choose according to its actual requirements rather than treating every UUID version as interchangeable.

Using UUID v4 in practice

Generate a UUID, take the value from the UUID v4 result field, and store the complete canonical string unless the receiving system specifies another representation.

1. Create a fresh UUID for the object or event that needs an identity.
2. Keep all five groups and four hyphens when passing it between systems.
3. Store it in a database UUID type where one is available. Otherwise, use a text or binary field sized for the chosen representation.
4. Add a unique constraint when the database must reject duplicate generated UUID v4 values.

Typical uses include identifying an order before it reaches the main database, correlating log entries across several services, naming an uploaded object, or assigning stable IDs to rows prepared for import. A UUID is often easier to merge across independently created data sets than local integer sequences, which may contain the same values in each source.

Spaces, punctuation, accented letters and non-Latin characters are not awkward input for UUID v4 because the generation process does not derive the identifier from text. If you need an identifier based on a name containing such characters, use a name-based UUID scheme and define the exact character encoding and normalisation rules. Otherwise, visually identical text can produce different byte sequences and therefore different identifiers.

Can two UUID v4 values ever be the same?

Yes, a collision is theoretically possible, but it is not a practical concern for ordinary UUID v4 use when generation uses a suitable random source. A v4 UUID has 122 variable bits because the remaining bits identify its version and variant, leaving an extremely large set of possible values.

"Universally unique" is therefore a practical description rather than a mathematical guarantee. Values copied or reused by mistake, implementation faults or poor random-number generation when the random source is inadequate can create more realistic duplication risks than chance alone. Systems that cannot tolerate duplicates should still enforce uniqueness at the database or application boundary.

A UUID also provides no proof that a request is genuine. Do not use a visible UUID by itself as authorisation, and do not assume that an object is protected merely because its address is difficult to guess. Access checks should apply to the underlying resource addressed by a UUID.

Frequently asked questions

Are UUIDs case-sensitive?

No, hexadecimal letters in UUID text are normally treated without regard to case, so A and a represent the same value. Lowercase is the usual canonical presentation, and normalising case before text comparison avoids inconsistent results in systems that compare strings case-sensitively.

Can I use a UUID v4 in a URL or file name?

Yes, the canonical form uses hexadecimal characters and hyphens, all of which are suitable for ordinary URL path segments and common file systems. Avoid adding braces unless a particular API requires them, and remember that exposing a UUID in a URL does not make the resource private.

Should I remove the hyphens from a UUID?

Only remove them when the receiving format explicitly expects 32 hexadecimal characters. Many libraries and database UUID types accept the canonical hyphenated form, which is easier for people to recognise and less likely to be confused with an unrelated hexadecimal value.

Is a UUID v4 suitable as a password or API secret?

No, an identifier and a secret have different purposes. Some UUID implementations may use suitable randomness, but the UUID format itself does not promise the handling, secrecy or entropy requirements of passwords, session tokens and API credentials. Generate credentials or tokens with a mechanism intended for that purpose, rather than with a UUID v4 generator.

Can a UUID v4 be personal data under UK GDPR?

Yes, it can be personal data when it identifies or can be linked to an identifiable person, even though the characters do not directly reveal a name. Treat UUIDs attached to customer accounts, devices or activity records according to the context and the organisation's retention and access rules.

Can I use UUID v4 as a database primary key?

Yes, many databases support UUID primary keys directly. Randomly distributed keys can cause less localised index insertion than ordered integer or time-based identifiers, so check database guidance for write-heavy tables. Keep a unique constraint in place and use one consistent storage representation across imports, queries and application code.