UUID Generator

UUID v5 is deterministic: the same namespace UUID plus the same name string always produces the same UUID. It uses a namespace, such as DNS, URL, OID, or a custom namespace, and hashes it with the name. This is useful when you need stable IDs for repeat imports, external references, or generated test data. Choose the namespace carefully, because changing it changes every resulting UUID. Do not use v5 for secrets; it is predictable by design. For random IDs, use UUID v4 instead.

A UUID is 128 bits, usually displayed as 36 characters with dashes. To shorten it, parse the UUID bytes as a 128-bit number and encode that number in Base62 or Base58. This can reduce the display length, but it is only safe if you preserve all 128 bits. Do not simply cut characters off the UUID, because truncation increases collision risk. Also decide whether your shortened form must be case-sensitive, URL-safe, and reversible. For public URLs, test copy-paste behavior carefully.

Use UUID v7 if your platform supports it. UUID v7 includes a Unix timestamp in milliseconds plus random or monotonic bits, so IDs generally sort by creation time while still remaining globally unique enough for practical use. This is helpful for database indexes, logs, and event records because newer records cluster together. Older UUID v4 values are random and do not sort by time. If v7 is not available in your stack, consider ULID or a database-native ordered ID, but confirm your team's standard first.

A standard UUID uses 128 bits. In the common text form, it has 32 hexadecimal characters plus 4 dashes, for a total of 36 characters, like 550e8400-e29b-41d4-a716-446655440000. Those dashes are just formatting; the actual value is still 128 bits. Without dashes, it is 32 hex characters. UUID versions use some bits for version and variant information, so not every bit is random, but the identifier space is still large enough for practical unique ID generation when created correctly.

Choose the UUID version you need, enter how many IDs you want, and generate the list. For most general app work, UUID v4 is a good random choice. For time-sortable records, use UUID v7 if supported. After generating, download or copy the results and keep one UUID per line or one per CSV row, depending on your workflow. Avoid editing them manually, because a small typo can make an ID invalid or duplicate. For production systems, generate IDs inside your application or database when possible.

A nil UUID is the all-zero UUID: 00000000-0000-0000-0000-000000000000. It is usually used as a special placeholder, default value, sentinel, or "no ID assigned" marker. It should not be treated like a real generated identifier. For example, an API might return a nil UUID when an optional relationship is missing, or a test system might use it as a known empty value. Be careful in databases: if many rows use nil UUID as a primary key, you will create duplicates and constraint errors.

The normal UUID string with lowercase hex characters and dashes is URL-safe in most practical cases. It does not contain spaces, slashes, question marks, ampersands, or other characters that usually break URLs. You can place it in a path segment or query parameter without special encoding. Still, always treat it as a value, not as trusted authorization. A UUID in a URL can be copied, logged, bookmarked, and shared. If the resource is private, check permissions on the server instead of relying on the UUID being hard to guess.

UUID hexadecimal letters are not case-sensitive for the value itself. For example, A and a represent the same hex digit. Many systems display UUIDs in lowercase because it is cleaner and avoids comparison surprises. However, some databases, filesystems, or string comparisons may treat uppercase and lowercase strings differently unless you normalize them. My recommendation is simple: store and compare UUIDs in a canonical lowercase form with dashes, or use a native UUID type in the database. That way, formatting differences do not create duplicate-looking values.

Yes. A UUID can be displayed without dashes as 32 hexadecimal characters. The dashes are part of the standard human-readable layout, not extra data. Removing them does not change the 128-bit value as long as all hex characters remain in the same order. This compact form is useful in filenames, database keys, or systems that do not allow hyphens. Just make sure every system in the workflow agrees on the format. When showing UUIDs to humans, the dashed version is usually easier to read and verify.