UUID
Generator
Generate UUID v4 identifiers instantly. Single or bulk, with format options. Fast, free, and entirely in your browser.
How It Works
Configure
Choose format options: uppercase, lowercase, with or without hyphens.
Generate
Click Generate for a single UUID or Generate Bulk for multiple.
Copy
Copy individual UUIDs or all at once to your clipboard.
Generate UUID v4 identifiers online for database keys, idempotency tokens, request IDs, and session tracking. ConverterUp's UUID generator creates one UUID or up to 100 at a time using the browser's cryptographically secure random source (crypto.randomUUID), so collisions are statistically impossible. Choose uppercase or remove the hyphens if your storage needs it, then copy one UUID or the whole list. Generation runs locally with no server round-trip, which guarantees that the IDs you receive are not logged, replayed, or reused anywhere outside your machine.
UUID versions: v1, v4, v7, and NIL
UUID v4 is the workhorse. 122 random bits plus 6 fixed version/variant bits, generated from a cryptographically secure RNG. Collision probability is so low (you would need to generate ~1 billion UUIDs per second for ~85 years to have a 50 % chance of a collision) that it can be treated as zero at internet scale. Use it as the default for almost everything.
UUID v1 encodes a 60-bit timestamp plus a MAC address and a clock sequence. It is sortable by creation time but leaks the host's MAC and the exact creation moment, which is a privacy concern. Most modern systems avoid v1 because of that leak and because the timestamp ordering is awkward (low bits come first).
UUID v7 (RFC 9562, 2024) is the modern alternative to v1: a 48-bit Unix-millisecond timestamp in the high bits, followed by random bits. It is lexicographically sortable, which makes it better for B-tree primary keys than v4. ConverterUp generates v4; if you need v7, most languages have a library for it (uuid in npm, uuid7 in Python).
NIL UUID (00000000-0000-0000-0000-000000000000) is a sentinel meaning 'no value' — useful as a default in optional FK columns or as a placeholder in tests. The Max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) is the equivalent ceiling sentinel for range queries.
UUID vs auto-increment integer IDs
Auto-increment integers (BIGSERIAL in Postgres, AUTO_INCREMENT in MySQL) are tiny (8 bytes), cache-friendly, and produce dense B-tree indexes. Their downside is that they leak business information — anyone seeing order=4217 can guess your order volume — and they make multi-master writes painful because the database server must coordinate the next value.
UUIDs are 16 bytes (2× the storage and index cost of a BIGINT), do not leak counts, can be generated client-side without a round-trip, and survive offline-first workflows where IDs need to exist before the row reaches the server. They are also URL-safe and globally unique across shards, services, and databases.
The pragmatic stack: UUID v7 for the primary key (good index locality, no count leak, client-generatable), an optional human-friendly BIGINT order_number column for display in the UI, and an optional opaque public_id (Nano ID or short hash) for URLs that need to look pretty.
Do not use UUID v4 as a primary key on a large hot table without thinking it through — its randomness causes severe write-amplification on B-tree indexes. Either use UUID v7, or use BIGINT primary keys with a separate UUID column for external references.
Storage formats: binary vs string, encoding choices
A UUID is fundamentally 16 bytes. Stored as a binary(16) or Postgres uuid type, it costs 16 bytes per row. Stored as the canonical hyphenated string (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), it costs 36 bytes plus per-row overhead — more than 2× the binary cost.
On Postgres, always use the native uuid type — it stores binary internally, accepts string input/output transparently, and supports indexing and ordering correctly. MySQL has no native UUID type; use BINARY(16) with helper functions UUID_TO_BIN and BIN_TO_UUID, optionally with the rearrangement flag for index-friendly storage.
For APIs, return the hyphenated string form. It is the universal exchange format. Base64 or Base58 encodings produce shorter strings (22 and 22 chars respectively vs 36) but break tooling — debuggers, log greps, and SQL clients all expect the hyphenated form. Save the encoded short forms for URL slugs only.
Frequently asked questions
Are these UUIDs safe to use as primary keys?
Yes. UUID v4 has 122 bits of randomness from a cryptographically secure source, giving a collision probability low enough to be ignored at internet scale. They are widely used as primary keys in PostgreSQL, MongoDB, and DynamoDB.
How many UUIDs can I generate at once?
Up to 100 per batch. Generate again for more; the list can be copied with one click and pasted into seed files or spreadsheets.
Can I generate other UUID versions?
The tool generates UUID v4, the most common version in application code. You can switch to uppercase and remove the hyphens depending on your storage requirements.
Are the UUIDs cryptographically secure?
Yes. They come from crypto.randomUUID, which uses the browser's cryptographically secure random generator — suitable for security tokens, session identifiers, and any case where guessability matters.
Can I get UUIDs without hyphens or in uppercase?
Yes. Toggle Uppercase for XXXXXXXX-… output and turn off Include Hyphens for the 32-character form. The bytes are identical across formats — only the textual representation differs.
What is the actual collision probability for UUID v4?
Negligible at any realistic scale. With 2^122 possible v4 UUIDs, generating 1 billion per second for 85 years gives a 50 % chance of a single collision. For a typical app generating millions per year, the probability is effectively zero — orders of magnitude less than the chance of a cosmic-ray bit flip in your database.