UUID/GUID Generator
Create cryptographically random version 4 UUIDs. Your work stays on this device whenever possible.
How to use UUID/GUID Generator
- Keep "Tool Mode" on "Generate New UUIDs", then choose "UUID Version": v4 (random), v7 (time-ordered), v1 (timestamp and node) or the Nil UUID.
- Set "Quantity" between 1 and 1000 (default 10) and switch "Casing" between lowercase and UPPERCASE.
- Tick or clear "Include Hyphens", "Wrap in Braces { ... }" and "URN Prefix (urn:uuid:...)" to match the notation your system expects.
- Press "Execute"; the list fills the result box and a notice such as "Generated: 10 V7 identifiers." appears above it.
- To inspect an existing ID, change "Tool Mode" to "Validate & Decode Existing UUID", paste it into the box and press "Execute" for version, variant and embedded time.
Worked example
Switch to Validate and paste 018e6e58-6c00-7f28-b8d9-379e4d0b1625. The report says Valid: true, Version v7 (Unix Epoch Time-Ordered) and Variant RFC 4122 / Leach-Salz. Its Timestamp line reads 2024-03-24T02:44:32.384Z, which is the first twelve hex digits, 018e6e586c00, read as milliseconds since 1970, followed by the same moment in your local time.
When to use this tool
- Seeding a test database with 100 uppercase, hyphenless identifiers.
- Checking whether an ID found in a log is v4 or v7 before choosing an index strategy.
- Producing urn:uuid: values for an XML identifier attribute.
Important limitations
UUID v4 relies on browser crypto.getRandomValues with 122 random bits. UUID v7 embeds millisecond timestamps in the most significant 48 bits for sequential B-tree database indexing.
Frequently asked questions
Should I pick v4 or v7?
A v4 value is 122 random bits from the browser's secure generator and reveals nothing about when it was made. A v7 value starts with a 48-bit millisecond clock, so values sort by creation time, which keeps database indexes tidier. Use v7 for primary keys and v4 when timing must not leak.
Does the v1 option expose my MAC address?
No. The node field is filled with random bytes and the clock sequence starts at a random number, so v1 values carry a timestamp but no hardware identity. Two values created in the same millisecond still differ.
Why does the decoder only give a time for some IDs?
Only v7 IDs get a decoded timestamp. A v1 ID is labelled "Timestamp" yet reports "Not timestamp-based", and versions other than 1, 4 and 7, such as name-based 3 and 5 or the Nil value, appear as "Custom / RFC 4122".
Can I validate an ID that has no hyphens?
Not at present. The checker demands the 8-4-4-4-12 layout and strips only braces and a urn:uuid: prefix. Put the hyphens back before pasting, and remember that unticking "Include Hyphens" when generating produces strings this validator rejects.
Can two generated IDs collide?
A clash between random v4 values is astronomically unlikely, but nothing is checked against your database and a batch is not deduplicated. Keep a unique constraint on the column rather than relying on luck.