How to generate UUIDs online
jsonsql.dev generates UUIDs instantly in your browser. No data is sent to any server — your UUIDs are created locally using the Web Crypto API.
Choose a version — select UUID v4 (random) or UUID v7 (timestamp-based) from the dropdown.
Set the count — use the slider or input to generate 1 to 100 UUIDs at once.
Copy your UUIDs — click Copy next to any UUID, or Copy All to get the entire batch.
Example
UUID v4 (random):
f47ac10b-58cc-4372-a567-0e02b2c3d479UUID v7 (timestamp-based, sortable):
0190d4a8-7b3c-7f12-9a4e-5c1d2e3f4a5bBatch output (5 UUIDs):
550e8400-e29b-41d4-a716-446655440000
6ba7b810-9dad-41d9-80b4-00c04fd430c8
7c9e6679-7425-40de-944b-e07fc1f90ae7
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11
b9f8c3d2-1a4e-4f6b-8c7d-9e0f1a2b3c4dFeatures
- Generate UUID v4 (random) using the Web Crypto API — cryptographically secure
- Generate UUID v7 (timestamp-based) — time-sortable, ideal for database primary keys
- Batch generate 1 to 100 UUIDs at once
- Format options: lowercase, UPPERCASE, or no dashes
- Copy individual UUIDs or copy all at once
- Validate any UUID — check if it's valid, detect the version
- Parse UUID v7 timestamps — extract the embedded date and time
- Dark and light theme support
- Works offline — no internet needed after the page loads
- 100% client-side — no data sent to any server
UUID v4 vs UUID v7
| Property | UUID v4 | UUID v7 |
|---|---|---|
| Random bits | 122 bits | 74 bits |
| Timestamp | No | Yes (48-bit ms) |
| Time-sortable | No | Yes |
| Database performance | Random inserts (fragmentation) | Sequential inserts (optimal) |
| RFC | RFC 9562 (was RFC 4122) | RFC 9562 |
| Collision risk | ~1 in 2^61 after 1B UUIDs | Near-zero (time + random) |
| Best for | General purpose IDs | Database keys, event logs |
UUID Generator vs other tools
| Feature | jsonsql.dev | uuidgenerator.net | uuidtools.com |
|---|---|---|---|
| Client-side only | Yes | No (server) | No (server) |
| UUID v7 support | Yes | No | No |
| Batch generate | 1-100 | 1-500 | 1-50 |
| UUID validation | Yes | No | Yes |
| v7 timestamp parsing | Yes | No | No |
| Format options | 3 (lower/upper/no-dash) | 2 | 1 |
| Dark mode | Yes | No | No |
| Works offline | Yes | No | No |
UUID versions explained
UUIDs (Universally Unique Identifiers) come in several versions, each with different generation strategies. Here is a comprehensive overview of the most important versions.
UUID v1 — timestamp + MAC address
UUID v1 combines a 60-bit timestamp (100-nanosecond intervals since October 15, 1582) with the node's MAC address. While this guarantees uniqueness across machines, it raises a privacy concern: anyone who reads a v1 UUID can extract the creator's MAC address and the exact time it was generated. For this reason, UUID v1 is rarely used in modern applications.
UUID v4 — fully random
UUID v4 is the most widely used version. It generates 122 random bits (the remaining 6 bits encode the version and variant), giving an astronomically large keyspace. UUID v4 requires no coordination between systems — any machine can generate one independently with virtually zero collision risk.
UUID v4 generates 122 random bits, giving 2^122 (5.3 x 10^36) possible values. The probability of generating a duplicate is astronomically low — you'd need to generate 1 billion UUIDs per second for 86 years to have a 50% chance of one collision.
UUID v7 — timestamp + random (the future)
UUID v7 was standardized in RFC 9562 (2024). It embeds a 48-bit Unix millisecond timestamp in the first 48 bits, followed by 74 random bits. This makes UUID v7 naturally sortable by creation time — a critical advantage for database indexing.
Why v4 is the most common today: it has been the standard since RFC 4122 and is supported everywhere. Why v7 is the future: it solves v4's biggest weakness (random index fragmentation) while maintaining the same ease of generation. Major databases like PostgreSQL 17+ now support native UUID v7 generation.
UUID v4 vs UUID v7: which should I use?
UUID v7 embeds a Unix millisecond timestamp in the first 48 bits, making UUIDs naturally sortable by creation time. This dramatically improves database index performance compared to random UUID v4.
| Criteria | UUID v4 | UUID v7 |
|---|---|---|
| Generation | Pure random (122 bits) | Timestamp (48 bits) + random (74 bits) |
| Ordering | None — completely random | Time-ordered (sortable by creation time) |
| Database index performance | Poor — random inserts cause B-tree fragmentation | Excellent — sequential inserts, minimal page splits |
| Privacy | No embedded info — fully opaque | Timestamp is extractable (creation time is visible) |
| Ecosystem support | Universal — every language, every database | Growing — PostgreSQL 17+, most UUID libraries |
| Standard | RFC 9562 (originally RFC 4122) | RFC 9562 (2024) |
| Best use case | General-purpose IDs, tokens, session IDs | Database primary keys, event logs, time-series data |
Rule of thumb: Use UUID v7 for database primary keys and anything that benefits from time-ordering. Use UUID v4 when you need maximum privacy (no embedded timestamp) or when compatibility with older systems matters.
Using UUIDs as database primary keys
UUIDs are increasingly popular as database primary keys, especially in distributed systems. Here are the trade-offs.
Advantages
- Globally unique — no central authority or coordination needed between services
- Merge-friendly — combine data from multiple databases without ID conflicts
- Non-sequential — attackers cannot guess or enumerate IDs (with v4)
- Generate anywhere — clients can create IDs before inserting, no round-trip needed
Disadvantages
- Larger size — 16 bytes vs 4 bytes (int) or 8 bytes (bigint)
- Index fragmentation (v4) — random UUIDs cause random B-tree inserts, increasing page splits and slowing writes by 2-10x
- Harder to debug —
f47ac10b-58cc-4372-a567-0e02b2c3d479is less readable than42 - JOIN performance — comparing 16-byte keys is slower than comparing 4-byte integers
Why UUID v7 solves the index problem
UUID v7's timestamp prefix means new UUIDs are always larger than older ones. In a B-tree index, this causes sequential appends rather than random inserts — the same pattern as auto-increment integers. Benchmarks show UUID v7 achieves write performance within 5-15% of auto-increment, while UUID v4 can be 2-10x slower.
UUID vs ULID vs nanoid
| Property | UUID v4 | UUID v7 | ULID | nanoid |
|---|---|---|---|---|
| Length | 36 chars (128 bits) | 36 chars (128 bits) | 26 chars (128 bits) | 21 chars (default) |
| Time-sortable | No | Yes | Yes | No |
| Standard | RFC 9562 | RFC 9562 | Community spec | Community spec |
| Database support | Native UUID type | Native UUID type | Stored as string/binary | Stored as string |
| Case sensitive | No | No | No (Crockford Base32) | Yes (URL-safe alphabet) |
| Best for | General IDs | Database keys | Database keys (shorter) | URLs, short tokens |
UUID format and structure
A UUID is a 128-bit identifier represented as 32 hexadecimal characters in 5 groups separated by hyphens, following the pattern 8-4-4-4-12.
f47ac10b-58cc-4372-a567-0e02b2c3d479
│ │ │ │ │
│ │ │ │ └── Node (48 bits)
│ │ │ └── Clock sequence (14 bits) + Variant (2 bits)
│ │ └── Version (4 bits) + Time/random (12 bits)
│ └── Time or random (16 bits)
└── Time or random (32 bits)Version bits
The version is encoded in the 4 most significant bits of byte 6 (the 13th hex character, position index 14 in the string including hyphens). For example, a UUID starting with xxxxxxxx-xxxx-4xxx-... is version 4.
Variant bits
The variant is encoded in the 2-3 most significant bits of byte 8 (the 17th hex character). For RFC 9562 UUIDs, the two most significant bits are 10, meaning the hex digit is one of 8, 9, a, or b.
Special UUIDs
- Nil UUID:
00000000-0000-0000-0000-000000000000— all zeros, used as a "not set" placeholder - Max UUID:
ffffffff-ffff-ffff-ffff-ffffffffffff— all ones, defined in RFC 9562
Generating UUIDs in different languages
Here is how to generate UUIDs in the most popular programming languages and tools.
JavaScript
// UUID v4 — built-in (Node 19+, all modern browsers)
const id = crypto.randomUUID();
// "f47ac10b-58cc-4372-a567-0e02b2c3d479"Python
import uuid
# UUID v4
id = uuid.uuid4()
# UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479')
# UUID v7 (Python 3.14+)
id = uuid.uuid7()Go
import "github.com/google/uuid"
// UUID v4
id := uuid.New()
// "f47ac10b-58cc-4372-a567-0e02b2c3d479"
// UUID v7
id, _ := uuid.NewV7()PostgreSQL
-- UUID v4 (built-in since PostgreSQL 13)
SELECT gen_random_uuid();
-- UUID v7 (built-in since PostgreSQL 17)
SELECT uuidv7();Command line
# macOS / Linux
uuidgen
# Linux (lowercase)
cat /proc/sys/kernel/random/uuidRelated tools
Frequently asked questions
What is the difference between UUID v4 and UUID v7?
UUID v4 uses 122 random bits and is the most widely used version. UUID v7 embeds a 48-bit millisecond timestamp in the first 48 bits, making it time-sortable — ideal for database primary keys that need sequential ordering.
What's the probability of a UUID collision?
For UUID v4, the collision probability follows the birthday paradox. After generating 2.7 x 10^18 (2.7 quintillion) UUIDs, you have roughly a 50% chance of one collision. For context, if every person on Earth generated 1 UUID per second, it would take about 11 years to reach that number.
Should I use UUID v4 or v7 for my database?
Use UUID v7 if your database supports it. UUID v7 is time-ordered, which means sequential B-tree inserts instead of random ones. This reduces index fragmentation, improves write throughput by 2-10x, and allows you to sort by creation time without an extra column. Use UUID v4 if you need maximum privacy (v7 leaks creation time) or if your stack does not support v7 yet.
What's the difference between UUID and GUID?
UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) refer to the same thing — a 128-bit identifier. "GUID" is the term used in Microsoft ecosystems (Windows, .NET, SQL Server), while "UUID" is the standard term used everywhere else (RFC 9562, Linux, PostgreSQL, most programming languages). The format and generation algorithms are identical.
Can I extract the timestamp from a UUID v7?
Yes. Paste a UUID v7 into the validator and the tool will parse the first 48 bits to extract and display the embedded Unix timestamp as a human-readable date. The timestamp represents the exact millisecond the UUID was created.
What is the Nil UUID?
The Nil UUID is 00000000-0000-0000-0000-000000000000 — all 128 bits set to zero. It is defined in RFC 9562 and commonly used as a placeholder meaning "no value" or "not set," similar to null or zero in other contexts.