UUID Generator — Generate Random UUID v4, v7 & v1 Online

A UUID is a standardized 128-bit identifier written as 32 hexadecimal digits grouped as 8-4-4-4-12 with hyphens — for example, 550e8400-e29b-41d4-a716-446655440000. The format is defined in RFC 4122 and extended in later standards. Each UUID carries version bits that reveal how it was created (random, time-based, name-based, and so on) and variant bits that mark which specification family it belongs to.

Unlike sequential integers, UUIDs can be created independently on different machines without coordinating a central counter. That makes them ideal for distributed systems, offline-first apps, and quick prototyping where you need a unique string right now.

Backend developers assign UUIDs as primary keys in PostgreSQL, MySQL, MongoDB, and other databases when they want opaque, non-guessable row identifiers. Frontend engineers generate temporary client-side IDs before a record syncs to the server. QA teams bulk-generate thousands of UUIDs to seed load tests, staging databases, or CSV import files.

DevOps and platform engineers paste UUIDs into Kubernetes resource names, Terraform state labels, and log correlation fields. Technical writers and support staff decode UUIDs found in error logs to check whether an ID is version 4 random or version 7 time-ordered. Students learning data modeling use UUID tools to see how version bits and timestamps appear in real output.

Select the Generate UUID tab and click one of the three version cards. UUID v4 is selected by default and is the right choice for most new projects. The tool immediately displays one freshly generated UUID in the large hero panel. Click Generate new UUID whenever you need a replacement, or Copy UUID to place the current value on your clipboard.

The UUID updates automatically when you switch versions, so you always see a fresh example of the type you selected. Output respects whichever format toggle is active — standard lowercase with hyphens is the most common choice for databases and JSON APIs.

UUID version 4 is what most people mean when they search for a random UUID or uuidv4. Sixteen bytes are filled with cryptographically secure random data. Two fixed bit patterns are applied: the version nibble is set to 4, and the variant bits mark the ID as RFC 4122 compliant. The remaining 122 bits are random, which makes guessing a valid ID practically impossible.

Use UUID v4 when you need a general-purpose unique string with no ordering requirement — user IDs, upload file names, correlation IDs in microservices, and session references in development. This tool uses crypto.getRandomValues and, when available, crypto.randomUUID in your browser, so generation happens locally without a network round trip.

UUID version 7 is designed for modern applications that want both uniqueness and chronological sort order. The first 48 bits encode a Unix timestamp in milliseconds. The remaining bits are random, and the version and variant nibbles are set to 7 and RFC 4122 respectively. Because the timestamp sits at the most significant end, UUID v7 values sort in creation order when compared as strings or stored in B-tree database indexes.

Choose UUID v7 when inserting many rows over time and you want to reduce random index fragmentation compared to UUID v4. It is a strong alternative to auto-increment integers in distributed systems where multiple writers cannot share a single sequence. After generating a v7 UUID here, you can paste it into the UUID Decoder tab to confirm the embedded timestamp matches the current time.

UUID version 1 combines a 60-bit timestamp based on the Gregorian epoch with a clock sequence and a node identifier. Classic v1 implementations derive the node from a network MAC address; this tool uses a random node ID with the multicast bit set, which is a common approach when hardware addresses are unavailable or undesirable for privacy.

UUID v1 appears in older enterprise systems, some message queues, and legacy drivers that expect time-ordered 128-bit IDs. Select the UUID v1 card when you need compatibility with tooling that assumes version 1 layout. The decoder shows the extracted creation time, clock sequence, and node hex when you paste a v1 UUID.

Pick UUID v4 when you want the simplest random ID with no embedded time information. It is the default in most ORMs, the most recognized format in search results for generate uuid and random uuid generator, and the safest general choice when sort order does not matter.

Pick UUID v7 when you care about insert performance and chronological ordering in indexed columns. Pick UUID v1 when an existing system or library explicitly requires version 1 layout. If you are starting a greenfield project today, v4 or v7 covers nearly every scenario; v1 remains for compatibility rather than new design.

Standard format outputs lowercase hex with hyphens — the form PostgreSQL uuid columns and most JSON APIs expect. UPPERCASE converts every letter to capitals, which some Windows-centric configs and legacy mainframe exports prefer. Braces wraps the UUID in curly braces like {550e8400-e29b-41d4-a716-446655440000}, matching certain COM and .NET conventions.

No hyphens removes separators for compact 32-character strings used in some NoSQL keys and URL-shortening schemes. URN adds the urn:uuid: prefix defined for formal URI contexts. All formats apply to both the single UUID display and the bulk list simultaneously, so you can copy or download consistently formatted output.

The bulk section supports quick presets of 10, 100, 1,000, and 10,000 UUIDs. Generation runs in chunks so large batches do not freeze your browser tab. After generation, a duplicate check confirms whether every UUID in the batch is unique.

Download or copy in four formats: plain text (one UUID per line), JSON array, CSV with a header row, or a PostgreSQL-friendly SQL snippet. The on-screen list previews the first 500 rows; the downloaded file always contains the full batch.

The UUID Decoder tab accepts plain hyphenated form, uppercase, braces, hyphen-free, or urn:uuid: prefixes. For valid UUIDs you see normalized form, version name, variant, and timestamp fields for v1 and v7.

A 16-byte breakdown table lists each byte offset, field group, hex value, and binary representation — useful when learning how version and variant nibbles are encoded. Batch validate mode accepts one UUID per line and marks each row valid or invalid with line numbers.

The Code snippets tab generates copy-ready starter code in JavaScript, Python, SQL, C#, and Go using your current UUID as an example value. JavaScript and Python show native v4 generation; other versions include the generated sample for paste-into-code workflows.

Every UUID on this page is created in your browser tab using the Web Crypto API. We do not receive, log, or store the values you generate or paste into the decoder. That makes the tool suitable for drafting production-style IDs on confidential projects, though you should still follow your organization's policy for secrets and production data.

Your preferred version, bulk count, and output format are saved in localStorage on your device so the page remembers your last settings. Clear site data in your browser to reset those preferences.

UUID v4 collision risk is astronomically low for practical batch sizes. Generating 10,000 random v4 UUIDs does not meaningfully increase collision probability compared to generating one. Database unique constraints and application checks remain good practice, but you should not expect duplicates from this tool under normal use.

UUIDs are not registered centrally. Two systems can theoretically produce the same v4 UUID by extreme chance, just as two shuffled decks could match order. For virtually all application scales, treating generated UUIDs as unique is standard industry practice.

Do not use a UUID as a password or bearer token by itself — length alone does not make it a secret credential. Do not double-encode UUIDs when your API already expects standard hyphenated form. When importing bulk UUIDs into a database, confirm the column type is uuid or char(36) and that you are not accidentally storing braces or URN prefixes unless intended.

Remember that v7 and v1 leak creation time. If exposing IDs publicly could reveal when a record was created, prefer v4 for external-facing identifiers.