UUID & GUID Generator
Generate cryptographically secure UUID v4, database-optimized v7, and custom formatted GUIDs instantly — ready to paste into your database, API, test fixtures, or code. Features time-ordered tracking, Microsoft GUID representations, Base64 conversion, and interactive structural decoding.
Generate cryptographically secure UUID v4, database-optimized v7, and custom formatted GUIDs instantly — ready to paste into your database, API, test fixtures, or code. Features time-ordered tracking, Microsoft GUID representations, Base64 conversion, and interactive structural decoding.
This tool is designed to provide a seamless experience for developers by handling complex operations directly in your browser with maximum speed and security.
UUID stands for Universally Unique Identifier. It is a 128-bit number formatted as a 36-character string in the pattern xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx — eight hex characters, a hyphen, four, a hyphen, four, a hyphen, four, a hyphen, twelve. There are approximately 5.3 undecillion possible UUID v4 values (that is 5.3 followed by 36 zeros). The probability of generating two identical UUIDs, even across separate systems generating millions of UUIDs per second, is so astronomically small that for all practical engineering purposes it is treated as impossible.
There are several UUID versions. Version 1 is timestamp-based — it encodes the time of generation and the MAC address of the generating machine, which makes it sortable but leaks information you usually do not want to expose. Version 3 and version 5 are name-based — they derive a deterministic UUID from a namespace and a name using MD5 or SHA1 respectively, so the same inputs always produce the same UUID. Version 4, which this tool generates, uses random or pseudo-random numbers for all significant bits — it carries no information about when or where it was generated, making it safe for public-facing identifiers.
UUID is sometimes called GUID (Globally Unique Identifier) — the terms are interchangeable. GUID is Microsoft's terminology, used extensively in .NET, SQL Server, and Windows APIs. UUID is the RFC 4122 standard term used in Linux, macOS, most databases, and the broader internet standards ecosystem. If someone asks you for a GUID, a UUID v4 is exactly what they need.
Read the Full GuideThis tool generates between 1 and 100 UUID v4 identifiers in a single click. Set the count, click Generate UUID v4, and the UUIDs appear immediately — each one is cryptographically random, properly formatted with hyphens in the standard positions, and ready to use directly in any system that accepts UUID identifiers. The generation uses the browser's Web Crypto API — specifically crypto.randomUUID() where available, falling back to crypto.getRandomValues() for older browsers. This is the same source of randomness your production application should use when generating UUIDs in JavaScript. The output is not pseudo-random seeded from Math.random() — it is cryptographically secure random data from the operating system's entropy pool, which is what makes these UUIDs suitable for security-sensitive use cases like session tokens, API keys formatted as UUIDs, or any context where predictability would be a risk. All generated UUIDs are displayed as a list, each on its own line. Copy all of them at once with the copy button, or copy a single UUID by clicking next to it. The format is always lowercase with hyphens — the RFC 4122 standard format that virtually all UUID parsers and database UUID columns expect.
1. Set the count in the Count field — enter any number from 1 to 100 depending on how many UUIDs you need. For a single identifier to paste into a database record or config file, leave it at 1. For seeding test data or populating a fixture file, enter the number of records you are creating — up to 100 at once.
2. Click Generate UUID v4 — the tool immediately generates the requested number of cryptographically random UUID v4 identifiers using the browser's Web Crypto API. Each UUID is formatted in the standard 8-4-4-4-12 hyphenated lowercase format that databases, APIs, and UUID libraries expect.
3. Copy all generated UUIDs at once using the copy button — the entire list is copied to your clipboard with each UUID on its own line, ready to paste into a seed file, a SQL INSERT statement, a JSON fixture, or anywhere else you need a list of UUIDs. For a single UUID, copy it directly from the output.
4. Use the UUIDs directly in your application — they are valid RFC 4122 UUID v4 identifiers and will be accepted by any UUID column in PostgreSQL, MySQL, MongoDB, SQLite, or any other database, as well as any UUID validator or UUID-typed field in your programming language's UUID library.
5. Generate again any time you need more — each click produces a completely new set of cryptographically random UUIDs with no relationship to any previously generated set. There is no state between generations — you can generate 100 UUIDs, close the tab, come back a week later, and generate 100 more with complete confidence they will not overlap with the previous set.
The standard alternative to UUIDs for database primary keys is an auto-incrementing integer. Integers are simple, but they expose information you often do not want to expose. If your user IDs are 1, 2, 3 and a user can see their own ID in a URL, they now know how many users you have, can estimate your growth rate by checking IDs over time, and can try to access other users' data by incrementing the ID. UUIDs have none of these problems — they are not sequential, not guessable, and reveal nothing about how many records exist or when they were created. The scenario where I reach for a UUID generator most often is seeding test data. I need 20 records in a test database, each with a realistic UUID primary key — not integer 1 through 20, which would never appear in a real production database. Generate 20 UUIDs here, paste them into a seed file or a SQL INSERT statement, and the test data looks and behaves like real data. The same applies to writing unit tests for code that processes UUIDs — you need realistic UUID strings to test against, and generating them here is faster than writing crypto.randomUUID() calls in a test setup script. UUID v4 is also the right choice for distributed systems where multiple services or multiple database nodes need to create records independently without coordinating on ID assignment. Two services that both use auto-increment integers will eventually create records with the same ID and collide. Two services generating UUID v4 identifiers can operate completely independently and will never produce the same ID.
Cryptographically secure — uses the browser's Web Crypto API (crypto.randomUUID or crypto.getRandomValues) not Math.random() so generated UUIDs are suitable for security-sensitive contexts
Bulk generation — generate 1 to 100 UUIDs in a single click for seeding test data populating fixture files or preparing database migration scripts
RFC 4122 compliant format — all UUIDs are output in the standard 8-4-4-4-12 hyphenated lowercase format accepted by all databases UUID libraries and validators
100% browser-based — your UUIDs are generated locally and never transmitted to any server so there is no risk of ID collision from a shared server-side generator
Copy all at once — the entire generated list can be copied to clipboard in one click with each UUID on its own line ready to paste into code or data files
No account or installation required — generate UUIDs instantly with no sign-up no API key and no configuration
Works offline — once the page loads UUID generation works without an internet connection since all randomness comes from the browser's local entropy pool
Stateless generation — each generation is completely independent with no shared state so UUIDs generated at different times or on different devices will never conflict
Generating primary key values for database records during development and testing
Seeding test fixtures and mock data files with realistic UUID identifiers
Creating correlation IDs for distributed system request tracing
Generating unique identifiers for API resources without a running database
Creating session tokens or temporary access identifiers in UUID format
Populating UUID columns in SQL migration scripts or seed files
Generating unique filenames for uploaded files in cloud storage
Testing UUID validation logic and UUID-typed fields in application code
Example Input
Count: 5
Example Output
a3f8c2d1-7e4b-4f9a-b562-1d8e3c7f2a09 558e8408-e29b-41d4-a716-446655440000 b1c4e891-2d3f-4a7b-9c8e-5f6a0b1d2e3f d7f2a016-3b5c-4e8d-a1f9-7c2e4b6d8f0a 9e1b3c5d-7f0a-4b2e-8d6c-3a5e7f9b1d2c
Invalid Count: The count field requires a positive integer between 1 and 100. Entering 0, a negative number, a decimal, or a non-numeric value will prevent generation. If you need more than 100 UUIDs at once, generate in batches of 100 and combine the results, or generate them programmatically in your application using crypto.randomUUID() in a loop.
Count Above Maximum: The tool generates a maximum of 100 UUIDs per click to keep the output manageable in the browser UI. For bulk generation of thousands of UUIDs — for example populating a large test database — generate multiple batches and append them, or write a short script: in Node.js, Array.from({length: 1000}, () => crypto.randomUUID()) generates 1000 UUIDs in one line.
Browser Does Not Support Web Crypto API: Very old browser versions do not support the Web Crypto API used for cryptographically secure UUID generation. If you see an error or the Generate button does nothing, update your browser. Chrome 92+, Firefox 95+, Safari 15.4+, and Edge 92+ all support crypto.randomUUID() natively. For older environments, use the uuid npm package which provides a polyfill.
Generated UUID Rejected by Database UUID Column: If your database rejects a generated UUID, the most common cause is case sensitivity — some older MySQL configurations require uppercase UUIDs while this tool outputs lowercase. Convert to uppercase before inserting: SELECT UUID_TO_BIN('your-uuid') in MySQL or simply uppercase the string in your application code. PostgreSQL and most modern databases accept lowercase UUIDs without any conversion.
Pasting UUIDs With Trailing Newlines Causing Parse Errors: When copying multiple UUIDs and pasting them into code, an extra newline at the end of the copied text can cause a parse error if your code splits by newline and processes each line as a UUID. The last element in the split array will be an empty string. Trim your input before processing: uuids.filter(id => id.trim().length > 0) in JavaScript or [u for u in uuids if u.strip()] in Python.
Using Math.random() to generate UUIDs in application code instead of a proper UUID library
Fix: Math.random() is not cryptographically secure — it uses a predictable pseudo-random algorithm seeded from system time that can be predicted or reverse-engineered. Never build UUID generation on top of Math.random(). In modern JavaScript and Node.js, use crypto.randomUUID() which is built into the platform and cryptographically secure. In older Node.js versions use the uuid npm package's v4() function which uses crypto.randomBytes(). In Python use uuid.uuid4() from the built-in uuid module. This tool uses the same Web Crypto API so its output has the same security properties as the correct library approach.
Storing UUIDs as VARCHAR instead of a native UUID type in the database
Fix: Storing a UUID as a VARCHAR(36) string works but wastes storage and makes index lookups slower. PostgreSQL has a native UUID column type that stores the value as 16 bytes rather than 36 characters — more than half the storage with faster index performance. MySQL 8+ has a native UUID type. SQL Server uses UNIQUEIDENTIFIER. MongoDB uses Binary subtype 3 or 4. If you are designing a new schema, use the native UUID type for UUID primary keys. If you are on MySQL and cannot use the native type, store as BINARY(16) using UUID_TO_BIN() on insert and BIN_TO_UUID() on read.
Using UUID v1 for public-facing identifiers
Fix: UUID v1 encodes the timestamp and MAC address of the machine that generated it. This means a UUID v1 leaks when the record was created and potentially which server generated it. In a REST API where UUIDs appear in URLs, UUID v1 values expose creation timestamps that you likely do not want public. Always use UUID v4 for public-facing identifiers — it is purely random and reveals nothing about when or where it was created. Reserve UUID v1 or v7 for cases where sortability by creation time is a specific requirement and you have control over who sees the IDs.
Treating UUID collisions as impossible and not handling them in code
Fix: UUID v4 collision probability is astronomically low — approximately 1 in 5.3 undecillion per pair. In practice you will never see a collision. But in a high-availability system you still need a unique constraint on your UUID primary key column, both to enforce database integrity and to catch the case where the same UUID is submitted twice due to a client retry rather than a true collision. Handle the unique constraint violation in your application code with a proper error response rather than assuming insertion always succeeds.
Generating UUIDs client-side in a browser and trusting them as canonical record IDs without server-side validation
Fix: Generating UUIDs on the client is fine for temporary IDs during a form session or for optimistic UI updates. But if a client-provided UUID is used as a permanent database record ID without server-side verification, a malicious client can submit any UUID — including one that happens to match an existing record — and potentially cause unexpected behavior depending on your application logic. Generate permanent record IDs server-side, or if you accept client-generated UUIDs, validate that the UUID does not already exist before using it as a primary key.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
SQL Cheatsheet
Complete guide to SQL statements including SELECT queries, WHERE filters, aggregate functions, JOIN types, and DDL commands.
Are these UUIDs truly unique?
Yes, to a degree of certainty that is indistinguishable from guaranteed in any real engineering context. UUID v4 has 122 bits of randomness, giving approximately 5.3 undecillion possible values. To have a 50% probability of a collision you would need to generate 2.7 quintillion UUIDs. At a rate of one billion UUIDs per second that would take 85 years. In practice, UUID v4 collision is treated as impossible — but you should still add a unique constraint to your UUID primary key column in the database to handle client retries and guarantee data integrity.
Can I generate other versions of UUIDs?
This tool generates UUID v4 only — the random variant that is appropriate for the vast majority of use cases. UUID v1 is timestamp and MAC address based (sortable but leaks information). UUID v3 and v5 are name-based (deterministic, not random). UUID v7 is a newer standard that combines a millisecond timestamp with random bits, giving time-sortable UUIDs that work well as database primary keys with sequential index insertion. If you need v7 or name-based UUIDs, use the uuid npm package in Node.js or the uuid Python library which support all versions.
Is it safe for production use?
The UUIDs this tool generates are cryptographically secure — they use the browser's Web Crypto API which draws randomness from the operating system's entropy pool, the same source used by production UUID libraries. However, this tool is primarily intended for development workflows: seeding test data, generating IDs for config files, populating migration scripts. For production systems, generate UUIDs in your application code using the appropriate library for your language rather than copying them from a browser tool.
What is the difference between UUID and GUID?
UUID and GUID refer to the same thing — a 128-bit unique identifier in the xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx format. UUID is the RFC 4122 standard term used in Linux, macOS, PostgreSQL, MongoDB, and most internet standards. GUID (Globally Unique Identifier) is Microsoft's term for the same concept, used in .NET, SQL Server, Windows APIs, and COM. If a Microsoft system asks for a GUID, provide a UUID v4 — they are interchangeable. The only formatting difference is that Microsoft systems sometimes display GUIDs in uppercase with curly braces: {A3F8C2D1-7E4B-4F9A-B562-1D8E3C7F2A09}.
How do I generate UUIDs in JavaScript, Python, Java, and Go?
In modern JavaScript and Node.js 14.17+: crypto.randomUUID() — one line, built in, no dependencies. In older JavaScript use the uuid package: import { v4 as uuidv4 } from 'uuid' then uuidv4(). In Python: import uuid then str(uuid.uuid4()) — built into the standard library, no pip install needed. In Java: UUID.randomUUID().toString() from java.util.UUID — also built in. In Go: use the google/uuid package, uuid.New().String(). In PHP: use Ramsey\Uuid\Uuid::uuid4()->toString() or in PHP 8.2+ the Symfony UuidFactory. All of these produce UUID v4 values identical in format and randomness quality to what this tool generates.
Should I use UUID or auto-increment integer as a primary key?
It depends on the context. Auto-increment integers are simpler, more storage-efficient, and produce sequential indexes that are faster for range queries and bulk inserts in most database engines. Use integers when: you have a single-server database, IDs do not appear in public URLs, and you do not need to generate IDs outside the database. Use UUIDs when: you have a distributed system where multiple nodes create records independently, IDs appear in public-facing URLs where you do not want to expose record counts, you need to generate IDs on the client before the record is persisted, or you are migrating data between systems that need a globally consistent identifier.
Why does my UUID column in MySQL reject UUID values from this tool?
MySQL has historically had mixed UUID support. If you are using a CHAR(36) or VARCHAR(36) column, the UUID should insert without issues. If you are using a BINARY(16) column with UUID_TO_BIN(), the function is available in MySQL 8.0+ but not in older versions. If you are seeing a data too long error, check your column definition matches the UUID length. If you are seeing invalid UUID format errors, verify the UUID is in the standard lowercase hyphenated format — some older MySQL configurations expect uppercase. You can uppercase in your application or use UPPER() in the INSERT statement.
Is UUID v4 suitable for use as a session token or API key?
UUID v4 is cryptographically random and has 122 bits of entropy, which is sufficient for many session token use cases. However, dedicated session token and API key generation libraries often use 256 bits of entropy (32 bytes) which provides a larger security margin. For low-to-medium sensitivity applications, UUID v4 as a session token is reasonable. For high-security applications — financial services, healthcare, authentication tokens that grant elevated privileges — use a dedicated token generation approach with 32 bytes of cryptographically random data encoded as base64url or hex. Never use UUID v1 as a session token since its timestamp component makes it partially predictable.
Recent Activity
No recent activity