HSHimanshu Sharma
Free Tools

UUIDs explained: what version 4 UUIDs are and how to use them

Himanshu Sharma · · 7 min read

Advertisement

Every system that stores things needs a way to name them. A customer, an order, an uploaded file, a log entry: each one needs an identifier that no other item has. The simplest identifier is a counter: 1, 2, 3, and so on. It works well in one database, and it breaks down when many systems create records at the same time, or when you do not want visitors to guess the next number. A UUID solves this by being unique without asking a central place for permission. The free UUID Generator creates random version 4 UUIDs in bulk, ready to copy. This guide explains what they are, how they are built and when they are the right choice.

What a UUID is

UUID stands for universally unique identifier. A UUID is a 128-bit value, written as 32 hexadecimal digits in five groups separated by hyphens, in the pattern 8-4-4-4-12:

123e4567-e89b-42d3-a456-426614174000

It is also called a GUID, short for globally unique identifier, a term common in Microsoft environments. The two names refer to the same kind of value.

The key idea is that you can generate a UUID on any machine, at any time, without coordinating with anyone, and the result is so unlikely to match any other UUID that you can treat it as unique.

How a version 4 UUID is built

There are several versions of UUID, each with its own way of choosing the bits. Version 4 is the simplest: it is almost entirely random.

Of the 128 bits, 6 are fixed and 122 are random. The fixed bits record the version and the variant:

  • The first digit of the third group is always 4. That is the version. In the example above, the third group is 42d3.
  • The first digit of the fourth group is one of 8, 9, a or b. That is the variant. In the example, the fourth group is a456.

So a version 4 UUID always looks like xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, where y is 8, 9, a or b and every x is random. If a value does not match that pattern, it is not a standard version 4 UUID.

The number of possible version 4 UUIDs is 2 to the power 122, which is about 5.3 times 10 to the power 36. Written out, it is 5,316,911,983,139,663,491,615,228,241,121,378,304.

How likely is a collision?

A collision means two generated UUIDs are the same. With 122 random bits the chance is extremely small. A standard estimate, the birthday approximation, says that if you generate n random identifiers, the probability that any two match is roughly n squared divided by two times the number of possibilities.

If you generate one billion version 4 UUIDs, that gives:

(10^9 × 10^9) / (2 × 5.3 × 10^36)  ≈  9.4 × 10^-20

That is about nine in a hundred quintillion. You are far more likely to be affected by a hardware fault than by a UUID collision. The assumption behind this is that the random bits come from a good source. A UUID made from a weak random number generator is a different matter, because a poor generator can repeat patterns. The generator on this site uses your browser's secure random facilities.

When to use a UUID

  • Database primary keys in distributed systems. Several servers or apps can create records independently and merge them later without clashes.
  • Public identifiers. A URL such as /orders/3b241101-e2bb-4255-8caf-4136c566a962 does not reveal how many orders exist or let someone guess the next one by adding 1. A random identifier is not security on its own, so you must still check permissions for each request.
  • Uploaded file names. Naming files with UUIDs avoids two users uploading photo.jpg and overwriting each other.
  • Request and trace IDs. Attach one to each request and include it in every log line, so you can follow it across services.
  • Idempotency keys. When an API client retries a request, sending the same key lets the server recognise it and avoid doing the work twice.
  • Test data. Quickly create realistic unique identifiers for fixtures and examples.

When a UUID is not the best choice

Small, single-database projects. An auto-incrementing integer is smaller, faster to index and easier to read in a support conversation. Use it when you do not need what a UUID gives you.

Primary keys in MySQL's InnoDB engine. Random UUIDs inserted as the primary key land in random positions in the index, which can slow inserts and use more space as the table grows. A UUID stored as text takes 36 characters, against 16 bytes if you store it in binary form. If you use UUID keys in MySQL, store them in a BINARY(16) column, or consider a time-ordered variant so new rows go to the end of the index. The indexes lesson and the primary keys lesson in the MySQL course explain why key order matters.

Values people must type or read aloud. A UUID is long and error-prone to type. For a short code that people copy, a shorter token is friendlier.

As a secret. A UUID is not a password or an access token. Version 4 values are random, but they are made to be identifiers, and the standard does not promise that they are suitable as secrets. Use a purpose-made secret generator for that, such as the Password Generator, or your framework's token tools.

Using the UUID Generator

  1. Open the UUID Generator.
  2. Choose how many UUIDs you need.
  3. Press Generate.
  4. Copy them all with one click and paste them where you need them, such as a spreadsheet, a seed file or a test.

Every time you press the button you get a fresh set, so there is no reason to reuse a value.

Generating UUIDs in code

You rarely need a website in production, because every platform has a library:

// JavaScript (modern browsers and Node.js)
const id = crypto.randomUUID();
# Python
import uuid
print(uuid.uuid4())

In PHP, frameworks provide a UUID helper, and a package from Composer is common. The namespaces and Composer lesson shows how to add one.

Common mistakes

  • Treating UUID letters as case sensitive. The standard says UUIDs are written in lowercase hexadecimal, but they should be compared without regard to case. Normalise to lowercase before you store or compare.
  • Dropping the hyphens in some places and not others. Choose one format for storage and stick to it.
  • Using UUIDs for security checks. A hard-to-guess URL is not authorisation. Always verify that the signed-in user may see the record.
  • Storing UUIDs as long text everywhere. It wastes space. Use a native UUID type if your database has one, or binary.
  • Using a weak random function in your own generator. Do not build one from Math.random() or similar. Use a library or the platform's secure function.

Related tools

To pretty-print the JSON that carries your identifiers, use the JSON Formatter. If you need to check how a value encodes, try the Hash & Encode Toolkit. Timestamps are the other value every record needs; the Unix Timestamp Converter shows them as dates.

Quick answers

Is a UUID the same as a GUID? Yes, for practical purposes. GUID is the name used in Microsoft documentation.

Can two UUIDs ever be the same? In theory yes, in practice the chance is negligible for random version 4 values.

Do UUIDs reveal anything about me? Version 4 contains no machine address or time. Some older versions did, which is one reason version 4 became popular.

What about other versions? Time-based versions put a timestamp at the front so values sort in creation order, which suits database keys. Version 4 stays the right choice when you simply want random.

Advertisement