UUID v4 generator

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

Server-side generation and privacy

The UUID is generated on the server. The request travels to the server over HTTPS, and the input is not stored. Because generation does not happen in your browser, claims that data never leaves your device would be inaccurate for this tool.

A UUID v4 does not require a name, email address, or other source text. It is generated from random or pseudorandom bits rather than calculated from something you type. The result field contains the generated UUID v4.

The tool does not state which server-side random-number source it uses, so do not assume the result is suitable as a password, encryption key, API token, or session secret. Those uses require a cryptographically secure secret generator and usually more explicit security guarantees.

How can I recognize a UUID v4?

A standard UUID v4 is a 128-bit value commonly written as 32 hexadecimal characters in five groups separated by hyphens.

The familiar text pattern is xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. Each x is a hexadecimal character from 0 through 9 or a through f. The first character of the third group is 4, which marks version 4. The y position is commonly 8, 9, a, or b because those values identify the standard UUID variant.

• The complete hyphenated representation has 36 characters.
• The group lengths are 8, 4, 4, 4, and 12 characters.
• The hyphens appear after character positions 8, 12, 16, and 20 when counting hexadecimal characters only.
• Hexadecimal letters may be displayed in lowercase or uppercase without changing the underlying value.

A generated result will follow that structure, but its random positions are not fixed by the UUID format. For example, the version group will begin with 4, while the remaining characters depend on the generated bits.

Why are UUID v4 collisions unlikely in normal use?

When values are generated independently with a suitable random source, UUID v4 collisions are not a practical concern for ordinary application workloads because each value has 122 random bits after the fixed version and variant bits are accounted for.

A collision occurs when two independent generation attempts produce exactly the same UUID. The possibility is mathematically real, so "universally unique" is not an absolute proof of uniqueness. However, the available space is so large that well-generated version 4 UUIDs are routinely used without coordinating a central counter or contacting a shared ID service.

Database constraints still matter when storing UUIDs. If a UUID identifies a row, place a unique constraint or primary-key constraint on that column. The constraint protects data integrity if a duplicate arrives because of a programming error, copied test fixture, failed import, or an exceptionally unlikely collision. In day-to-day systems, accidental reuse caused by application code is usually a more realistic problem than two independent random generations matching.

Where do UUID versions fit?

Choose UUID v4 when you need an identifier that can be generated independently and does not need to reveal creation time or carry application-specific meaning.

In one line, UUID v1 is time-and-node based, v2 is an uncommon DCE security form, v3 and v5 derive IDs from a namespace and name, v4 is random, v6 rearranges time-based fields for database ordering, v7 combines a Unix timestamp with random data, and v8 is intended for experimental or vendor-specific formats.

Version 3 or 5 fits deterministic identification. Given the same namespace, name, and version, an implementation produces the same UUID, which can help when separate systems must agree on an ID. Version 7 is often considered when roughly time-ordered values are useful for indexing. Version 4 is a straightforward choice when independence and opacity matter more than chronological order.

A version 4 UUID is an identifier, not a checksum. It does not confirm that a file or message is unchanged, and it cannot be reversed to recover source data. For an ordinary random integer within a defined range instead, use a Random number generator rather than treating part of a UUID as a number.

What should I check before saving or sending the result?

Check the receiving system's expected representation before storing or transmitting the UUID. Many databases have a native UUID type, while APIs and configuration files commonly use the 36-character hyphenated text form.

1. Copy the entire value, including every hexadecimal character and hyphen, unless the destination explicitly requires another representation.
2. Store it in a UUID-native column when the database supports that type. Otherwise, choose a text or binary representation consistently across the application.
3. Add a uniqueness constraint to the UUID column when duplicate UUID-backed records would cause a problem.
4. Do not attach meaning to sections of a version 4 UUID. Most of its bits are random, while a few bits identify the version and variant.
5. Treat logging and sharing according to what the UUID points to. A harmless-looking ID may provide access to a customer record, private document, or internal request when combined with an application endpoint.

Spaces, quotation marks, braces, commas, and line breaks are not part of the canonical UUID text itself. They may appear when a UUID is embedded in JSON, a spreadsheet, a log line, or source code. Remove surrounding syntax only when the destination expects the bare UUID.

Accented letters, emoji, and non-Latin characters cannot appear in a UUID because its text representation uses hexadecimal characters and hyphens. Numbers are allowed only as hexadecimal digits within the defined positions. Empty text is not a UUID, and very long text should not be truncated in hopes of producing one. Generate a fresh value instead.

Frequently asked questions

Is a UUID the same as a GUID?

The terms are commonly used interchangeably, especially in Microsoft systems, but their formatting conventions can differ by platform or API. When integrating with a specific service, follow its documented byte order and text representation rather than relying only on the label.

Can UUID v4 values be sorted by creation time?

No. Version 4 does not encode creation time, so lexical or numeric sorting does not reliably reproduce generation order. Store a separate timestamp or consider UUID v7 when chronological ordering is a design requirement.

What is the nil UUID?

The nil UUID has every bit set to zero and is commonly written as 00000000-0000-0000-0000-000000000000. It is a reserved sentinel value rather than a generated UUID v4, and some systems use it to mean missing, unknown, or unassigned.

Does seeing a 4 in the version position prove a UUID is valid?

No. The version digit and correct length are only structural checks. A value can match the UUID v4 pattern and still have been typed manually, duplicated, or produced by a weak generator, so format validation cannot establish origin or randomness.

Should a UUID be treated as confidential?

The UUID value itself is generally an identifier rather than a secret, but context can make it sensitive. Avoid publishing it when possession of the identifier reveals private records, exposes internal infrastructure, or functions as the only barrier to accessing a resource.