Single v4 UUID
Input
count: 1 uppercase: off
Output
550e8400-e29b-41d4-a716-446655440000
Position 13 is always `4` (version) and position 17 is one of `8`, `9`, `a`, or `b` (variant). The remaining 122 bits are random — `e8400`, `e29b`, `1d4`, etc.
Loading…
All processing runs in your browser — no files or inputs are uploaded to a server.
How to use
Set how many UUIDs to generate (1–100) and click Generate. Each is a fresh v4 UUID — 122 bits of cryptographic randomness sourced from the browser's WebCrypto API, with no time, MAC address, or counter encoded inside. Toggle Uppercase if your downstream system stores hex in upper case (some legacy SQL Server and Oracle setups do).
Reach for this when you need an identifier that is unique without a coordination round-trip: a draft record ID before the database insert, an idempotency key for an HTTP retry, a correlation ID for a log trace. The output is purely random and not sortable — if you need IDs that order by creation time, look at UUID v7 or ULID instead. Generation happens entirely in the browser, so no value is ever sent to a server.
Examples
Bulk generation for a seed file
Input
count: 5 uppercase: off
Output
a1b2c3d4-5e6f-4a7b-8c9d-0e1f2a3b4c5d f9e8d7c6-b5a4-4392-8170-6f5e4d3c2b1a 7c8d9e0f-1a2b-4c3d-9e8f-0a1b2c3d4e5f 3b4c5d6e-7f80-4192-a3b4-c5d6e7f80a1b 12345678-9abc-4def-9012-3456789abcde
Bulk mode (up to 100) is handy when seeding test fixtures, populating a `WHERE id IN (…)` clause for staging data, or pre-issuing idempotency keys for a batch job. Copy All to grab the whole list at once.
Uppercase for legacy systems
Input
count: 1 uppercase: on
Output
550E8400-E29B-41D4-A716-446655440000
RFC 4122 §3 says generators "should output lower case" but parsers must accept both. SQL Server's UNIQUEIDENTIFIER and Oracle's RAW(16) print upper case by default — matching that style on input avoids visual diff churn in fixtures.
FAQ
Will I ever generate a duplicate?
In practice, no. v4 has 122 random bits = ~5.3 × 10^36 distinct values. The 50% collision threshold (birthday paradox) is around 2.71 × 10^18 generated UUIDs. Generating a billion per second for a hundred years would still leave the collision risk below detection threshold. Treat duplicate v4 UUIDs as a code bug (uninitialized RNG, repeated buffer) rather than a probability event.
Is v4 a good primary key for my database?
Functional yes, performance often no. Random IDs scatter inserts across the B-tree, fragmenting pages and shrinking buffer cache hit rate — PostgreSQL, MySQL, and SQL Server all feel this on high-write tables. UUID v7 (time-ordered) or ULID solve the locality problem while keeping the no-coordination property. If you must use v4, consider keeping a sequential `bigserial` for clustering and the UUID as a secondary lookup key.
What's the difference between v1, v4, and v7?
v1 mixes a 60-bit timestamp with the host's MAC address — sortable but leaks where the ID was minted. v4 is fully random — no leak but unsortable. v7 (RFC 9562, 2024) puts a 48-bit Unix millisecond timestamp at the front then random bits — sortable, no MAC leak, drop-in compatible with v4 storage columns. v3 and v5 are deterministic hashes over a namespace and a name, used when the same input must always produce the same UUID.
Is `crypto.randomUUID()` cryptographically safe enough for tokens?
For most purposes yes — the underlying CSPRNG is the same one that powers WebCrypto subtle key generation. But 122 random bits is below the 128-bit floor recommended for long-lived bearer tokens or session IDs in OWASP ASVS. For those use a dedicated random-bytes function (`crypto.getRandomValues(new Uint8Array(32))` + base64url) rather than a UUID.
Can I get the UUID without dashes?
Not directly — the tool emits the canonical 8-4-4-4-12 form. Strip dashes after copy with `s/-//g` (sed), `replace(/-/g, "")` (JS), or a manual find-replace. RFC 4122 lets parsers accept either form, but the canonical form is what most logs and APIs expect.
UUID vs ULID vs nanoid — when do I use which?
UUID is the interoperable default — every language and database understands the 128-bit form. ULID encodes the same 128 bits as a 26-character Crockford base32 string, time-prefixed and lexicographically sortable — nicer in URLs. nanoid is a 21-character URL-safe random string with comparable collision resistance and a much smaller library footprint than UUID v4 implementations. For cross-system identifiers stay with UUID; for shorter URL-visible IDs ULID or nanoid are reasonable.
Related concepts
A UUID (Universally Unique Identifier) is a 128-bit value rendered as 32 hexadecimal digits with four hyphens (`xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx`). The `M` nibble carries the version and the `N` nibble carries the variant, leaving up to 122 bits for the payload depending on the version. The form was originally specified by RFC 4122 (2005) and updated by RFC 9562 (May 2024), which introduced v6, v7, and v8.
The versions trade off three properties: sortability, privacy, and determinism. **v1** (timestamp + MAC) is sortable but identifies the originating host. **v3 / v5** (namespace + name hash, MD5 / SHA-1) are deterministic — same input always yields the same UUID, useful for stable IDs derived from external identifiers. **v4** (random) is the privacy-preserving but unsortable default; this tool generates v4. **v6** rewrites v1 timestamps for byte-level sort order. **v7** prefixes a 48-bit Unix-millisecond timestamp then random bits — the modern recommendation for database primary keys.
UUIDs sit between two adjacent ideas. Auto-increment integers (`bigserial`, `AUTO_INCREMENT`) require a single coordinator and reveal record counts but stay small and sort-friendly. Cryptographically random tokens (`crypto.getRandomValues(32)` → base64url) carry more entropy than UUID v4 (256 vs 122 bits) and are the right choice for session cookies or password reset links. UUIDs hit the middle: enough randomness for distributed generation, standardized format for every database driver, but not enough entropy for security-critical tokens.
Related articles
Related tools
Cron Parser & Builder
DeveloperValidate a 5-field cron expression and preview the next N execution times, or build one from a frequency picker (minute/hour/day/week/month/year).
JSON Formatter
DeveloperFormat and validate JSON. Indented or minified output, with clear error messages.
Base64 Encoder / Decoder
DeveloperEncode text to Base64 or decode Base64 back to text. UTF-8 safe.
URL Encoder / Decoder
DeveloperPercent-encode or decode URL components.