UUID Generator
Generate RFC 4122 compliant unique identifiers
Click "Generate UUID" to start
What is UUID?
A UUID, or Universally Unique Identifier, is a 128-bit identifier used to label records, objects, sessions, files, devices, messages, and other entities across distributed systems. Its familiar text form uses hexadecimal groups in an 8-4-4-4-12 pattern. UUIDs solve the case where multiple servers, clients, or services need to create identifiers without asking a central database for the next sequential number. Different UUID versions are generated from randomness, time information, or namespace-based hashes, which affects privacy, sortability, predictability, and collision risk. This tool is suitable for generating and inspecting UUIDs quickly, but a UUID is still only an identifier and should not be treated as authorization or secret security material.
How to Use
Generation Steps
- Select UUID version (v1, v4, or Nil)
- Set generation count (1-100)
- Choose output case (upper or lower)
- Select format (with hyphens, no hyphens, or braces)
- Click the Generate button to create the requested identifiers
Keyboard Shortcuts
- Ctrl + GGenerate UUID
- Ctrl + Shift + CCopy All
Identifier Notes
- UUID v4 is usually the right choice for random client-side identifiers; it does not encode time or device information.
- Do not use UUIDs as secrets. They identify records but are not a substitute for authentication tokens or access keys.
Use Cases
Technical Principle
UUID is a 128-bit identifier in the standard form 8-4-4-4-12, 36 characters in total (including 4 hyphens). The 128 bits are split into: time-low (32 bits), time-mid (16 bits), version-and-time-high (16 bits, top 4 bits are the version), variant-and-clock-seq (16 bits, top 2 to 3 bits are the variant), and node (48 bits). RFC 4122 defines five versions, v1 through v5. v1 is built from a 60-bit timestamp (100-nanosecond resolution, counted from 15 October 1582) plus a 48-bit MAC address plus a 14-bit clock sequence. It is theoretically sortable by generation time, but it leaks the machine identity and generation time. v4 is the most widely used version: 122 bits filled with a cryptographically secure random source, and fixed version (4) and variant (10) bits. Collision probability is a central concern in UUID design. v4 has 122 bits of random space, and by the birthday paradox it takes a billion UUIDs per second for 85 years straight to reach a 50% chance of a single collision, which is more than enough in practice. The emerging v7 places the timestamp first and the random bits last, balancing uniqueness and time ordering, and is better suited for database primary keys.
- UUID v4: 122 random bits with fixed version bit 4 and variant bit 10; works for almost every scenario and leaks no privacy
- UUID v1: 60-bit timestamp + 48-bit MAC + 14-bit clock sequence; sortable by time but exposes the machine fingerprint, use with care
- UUID v7: timestamp first, random bits last; a 2024 draft standard designed specifically for database primary keys
- Collision probability: v4's random space is 2^122, and a billion UUIDs per second for 85 years straight is needed for a 50% chance of one collision
- Nil UUID: all zeros 00000000-0000-0000-0000-000000000000, commonly used as a placeholder or default value
- Format variants: beyond the standard 8-4-4-4-12 there is the 32-character no-hyphen form, the {braces} form, and the URN form (urn:uuid:...)
Examples
UUID v4 (random) standard format
550e8400-e29b-41d4-a716-446655440000
Version digit (13th hex char): 4 -> v4, random
Variant bits (17th hex char): 8/9/a/b -> RFC 4122 variant
Use: primary keys in databases, request IDs, asset IDs - the default choice when order does not matter
RFC: RFC 4122 section 4.4 defines v4 generationUUID v1 (timestamp + MAC) format
c232ab00-9414-11ec-b909-0242ac120002
Version digit: 1 -> v1, time-based
Note: encodes the generation timestamp in time_low; the last 12 hex chars are the node id (often a MAC)
Use: when you need sortable IDs or a deterministic per-host source, but be aware the MAC leaks host identity
RFC: RFC 4122 section 4.1 defines v1 layoutBatch generate 5 v4 IDs
a1b2c3d4-e5f6-4789-a012-3456789abcde
f7e8d9c0-b1a2-43f4-95e6-7d8c9b0a1e2f
3c4d5e6f-7a8b-49c0-9d1e-2f3a4b5c6d7e
8e9f0a1b-2c3d-44e5-bf6a-7b8c9d0e1f2a
5f6a7b8c-9d0e-45f1-a2b3-c4d5e6f7a8b9
Note: each ID is independently drawn from crypto.getRandomValues; collision probability for 2^122 IDs is negligible per RFC 4122 Appendix BFAQ
What is a UUID?
A Universally Unique Identifier is a 128-bit value (RFC 4122/9562) usually written as 32 hex digits in the 8-4-4-4-12 pattern, e.g. 550e8400-e29b-41d4-a716-446655440000. Different versions encode time, random data, or hashes; their purpose is to be unique across systems without a central coordinator.
What is the difference between UUID v1, v4, and v7?
v1 mixes the host MAC address and a 100-ns timestamp (good ordering, leaks host info). v4 is purely random (122 bits of entropy, no ordering). v7 (RFC 9562) puts a 48-bit Unix-ms timestamp in the high bits with random low bits - sortable like v1 but with no MAC leak. v7 is the modern default for database keys.
Is a UUID truly unique?
Statistically, yes. Generating a billion v4 UUIDs per second for 100 years still gives a collision probability of roughly 50% (the birthday-paradox bound). For all practical systems, you can treat UUIDs as unique without coordination.
Are UUIDs random and unguessable?
v4 UUIDs are random and effectively unguessable (122 bits of entropy). v1 UUIDs are not random at all - they expose the host MAC and timestamp, so do not use v1 as a security token. v7's timestamp prefix is also predictable; only the trailing random bits are unguessable.
Should I use UUID as a database primary key?
It works but has trade-offs. Random v4 UUIDs cause B-tree fragmentation in databases that cluster on the primary key (MySQL InnoDB), hurting insert performance at scale. Sortable v7 UUIDs avoid that. Auto-increment integers are still smaller and faster - use UUIDs when distributed generation matters.
Is UUID generation done in my browser?
Yes. The page uses crypto.randomUUID (or crypto.getRandomValues for older browsers) which is part of the Web Crypto API. Nothing is sent to a server, and refreshing the page gives a fresh entropy stream.
Why do some UUIDs look almost the same at the start?
v1 and v7 UUIDs encode time in their leading characters, so UUIDs generated within the same millisecond share a prefix and only differ in trailing bytes. That property is what makes them naturally sortable. v4 UUIDs are random and do not exhibit this.