UUID / GUID Generator
Generate Version 4 UUIDs instantly — one at a time or in bulk up to 500. Format them exactly how your database or API expects, copy with one click, and move on. Everything runs in your browser; nothing touches a server.
Configuration
What a UUID is and what this tool generates
A UUID (Universally Unique Identifier) is a 128-bit value standardized in RFC 4122, typically written as 32 hexadecimal characters in five groups:
550e8400-e29b-41d4-a716-446655440000This tool generates Version 4 UUIDs specifically. V4 fills 122 of those 128 bits with random data (the remaining 6 bits indicate the version and variant). That randomness is what makes UUIDs safe to generate independently on any machine without coordinating with a central ID server.
We use the browser's window.crypto.getRandomValues() API — the same entropy source used for TLS and Web Crypto operations — rather than Math.random(), which is not cryptographically secure.
Format options — which one does your stack want?
The same UUID can be represented several ways. Pick the format that matches what your ORM, database column type, or API expects — a mismatch causes silent bugs that are annoying to track down.
1f48ab03-a249-43af-8d69-cf5cd76e0539Default. Works with most ORMs, REST APIs, and Postgres UUID columns.
1F48AB03-A249-43AF-8D69-CF5CD76E0539Required by some .NET libraries and older SQL Server conventions.
1f48ab03a24943af8d69cf5cd76e0539Common in URLs, Redis keys, and CSRF tokens where dashes are awkward.
1F48AB03A24943AF8D69CF5CD76E0539Matches BINARY(16) hex representation in MySQL. Also used in some Java UUID toString() overrides.
Where developers actually use UUIDs
UUIDs solve a specific problem: generating a unique identifier without asking anyone's permission. Here are the situations where that property matters most.
Database primary keys
Auto-incrementing integers are predictable — an attacker hitting /api/orders/42 can trivially scrape your data by incrementing the ID. UUIDs close that hole. Because they're unguessable, every request to a private resource requires actual authorization, not just knowledge of the next integer.
Idempotency keys for APIs
When you send the same payment or mutation request twice (network retry, user double-click), the server needs a way to know it already processed it. Pass a UUID as an idempotency key — the server stores it and returns the cached result instead of charging twice.
Request correlation and tracing
Assign a UUID to every incoming HTTP request and pass it through every downstream service call. When something fails in a distributed system, you can grep logs across services for that single ID and reconstruct exactly what happened, in order.
Test data and fixtures
Seeding a database with 200 mock users requires 200 unique user IDs that won't conflict with each other or with production data. Generate a batch here, paste it into your seed file, and you're done. No collision checking needed.
Guest sessions and anonymous state
Assign a UUID to every unauthenticated visitor on arrival. You can associate a cart, preferences, or browsing history with that session without requiring a login — and merge it into their account later if they sign up.
File and asset naming
Storing user uploads with their original filename creates collisions and exposes information. Rename every uploaded file to a UUID on arrival. The original name lives in your database; the file on disk is unguessable.
How to use bulk generation
Set the quantity field to any number up to 500 and click Generate. The output is a plain list — one UUID per line — so you can paste it directly into a seed file, a CSV, or a terminal variable.
INSERT INTO users (id, name) VALUES
('1f48ab03-a249-43af-8d69-cf5cd76e0539', 'Test User 1'),
('a3c2d1e0-f456-4789-b012-345678901234', 'Test User 2');const ids = [ '1f48ab03-a249-43af-8d69-cf5cd76e0539', 'a3c2d1e0-f456-4789-b012-345678901234', // paste the rest here ];
UUID v4 vs. other unique ID strategies
UUID v4 is the right default for most situations, but it's not always the best tool. Here's how it compares to alternatives you might encounter.
| Format | Sortable | Length | Notes |
|---|---|---|---|
| UUID v4this tool | No | 36 chars | Best general-purpose choice. Purely random, no embedded metadata. |
| UUID v1 | Partial | 36 chars | Embeds MAC address + timestamp. Traceable — avoid for user-facing IDs. |
| ULID | Yes | 26 chars | Timestamp prefix makes it lexicographically sortable. Good for event logs. |
| NanoID | No | Configurable | Shorter and URL-safe. Collision risk rises sharply if you reduce the length. |
| Auto-increment | Yes | ~4–10 chars | Fastest to index, but IDs are guessable. Never use for public-facing endpoints. |
If you need sortable IDs — for example, to paginate efficiently or sort rows without a separate created_at column — look at ULID or the newer UUID v7, which encodes a millisecond timestamp in the leading bits.
Storing UUIDs in a database — what actually matters
The column type you choose has a real impact on performance at scale. The difference between VARCHAR(36) and BINARY(16) is subtle at 10,000 rows and significant at 50 million.
VARCHAR(36)- + Human-readable in queries
- + No conversion code needed
- + Works everywhere
- − 36 bytes vs. 16 bytes
- − Slower index scans at scale
- − String comparison overhead
Fine for most projects and any table under a few million rows.
BINARY(16)- + Half the storage of VARCHAR
- + Faster index operations
- + Better cache utilization
- − Not human-readable in SQL clients
- − Requires hex conversion on read/write
- − More ORM configuration
Worth the complexity for high-volume tables or when UUIDs are foreign keys on many joins.
-- MySQL: store as BINARY(16) CREATE TABLE sessions ( id BINARY(16) NOT NULL DEFAULT (UUID_TO_BIN(UUID())), PRIMARY KEY (id) ); -- Query using BIN_TO_UUID() SELECT BIN_TO_UUID(id) FROM sessions;
Limitations worth knowing
UUID v4 handles the vast majority of use cases well, but there are real scenarios where it's the wrong choice.
Index fragmentation in B-Tree indexes
Because v4 UUIDs are random, each new row inserts in a random position in a sorted index. This causes page splits and fragmentation over time, which slows down both reads and writes. Auto-incrementing integers or time-prefixed IDs (ULID, UUIDv7) insert at the end of the index and avoid this entirely. If your table does heavy write throughput and UUID index fragmentation becomes a real problem, UUIDv7 is the most compatible upgrade path.
Not suitable as a cryptographic secret
A UUID generated via window.crypto is random enough for IDs and tokens, but it's not designed to be a secret in the cryptographic sense. For API keys, signing secrets, or anything where unguessability is a security requirement, generate a proper secret using crypto.randomBytes(32) and encode it as base64 or hex. UUIDs have a known format and length — that's useful metadata for an attacker.
Collision probability is low but not zero
To have a 50% chance of a single collision, you'd need to generate approximately 2.71 quintillion v4 UUIDs. For any practical application this is irrelevant. If you're in a domain where even a 1-in-a-quintillion chance matters (aviation safety systems, medical device identifiers), you need a different architecture entirely — not a different UUID version.
Frequently asked questions
What is a UUID and when should I use one?+
A UUID (Universally Unique Identifier) is a 128-bit identifier, usually written as 32 hex characters split into five groups by hyphens. Use one wherever you need a unique ID that doesn't require a central authority to assign it — database primary keys, session tokens, request correlation IDs, and idempotency keys are the most common cases.
What makes Version 4 different from other UUID versions?+
Version 4 uses random or pseudo-random numbers for all 122 of its variable bits. V1 embeds a MAC address and timestamp (making it traceable). V3 and V5 hash a namespace and name (deterministic, useful for reproducible IDs). V4 is the right default when you just need a collision-resistant unique ID with no embedded metadata.
Are the UUIDs generated here logged or stored?+
No. Generation runs entirely via the browser's built-in window.crypto.getRandomValues() API. Nothing is sent to a server. The IDs exist only in your browser's memory until you copy them.
Should I store UUIDs as VARCHAR or BINARY in my database?+
VARCHAR(36) works and is readable, but BINARY(16) is significantly more efficient — it's half the storage size and indexes much faster. The tradeoff is that binary storage is less convenient to inspect manually. For high-volume tables with millions of rows, BINARY(16) is worth the extra handling code.
What's the difference between UUID and GUID?+
They're the same thing. GUID (Globally Unique Identifier) is Microsoft's term, used heavily in .NET and SQL Server. UUID is the RFC 4122 standard term used in most other ecosystems. The format and collision properties are identical.
When is a UUID the wrong tool?+
When you need sortable IDs. Because v4 UUIDs are random, they cause index fragmentation in B-Tree indexes as rows are inserted in non-sequential order. If you need both uniqueness and chronological sortability, consider ULID or UUIDv7 instead.
Generated locally, never transmitted
Every UUID is generated using window.crypto.getRandomValues() — a native browser API with OS-level entropy. No network request is made. Your IDs are never sent to or logged by Kodivio.