Skip to content

UUID Generator Online Free

Generate cryptographically random UUIDv4 identifiers, single or in bulk, with optional uppercase and dash-stripped formats.

In your browser—your files never leave your device.

Learn more
Random — 122 bits of entropy. The default for most app use.
⌘Enter gen · ⌘⇧C copy all

About this tool

A UUID is a 128-bit identifier with extremely low collision probability — 32 hex digits laid out as 8-4-4-4-12 with hyphens, per RFC 4122. Version 4 (the random variant) is the one you reach for most often, generated from 122 bits of entropy. This tool uses crypto.randomUUID, the Web Crypto API call exposed in every current browser, which is the same code path your Node 19+ or Deno backend uses. Output is deterministic in format and indeterministic in content: always 36 characters, always 5 groups, always lowercase by default, always RFC 4122 compliant for version and variant bits. Generate one, generate a hundred, copy the lot. Toggle uppercase or strip dashes if your downstream system has specific format requirements.

How to uuid generator online free

  1. Set the count

    How many UUIDs you need. The input goes 1 to 100. For more, generate multiple batches and concatenate. The default of 1 covers the "I just need an ID right now" case, which is by far the most common.

  2. Pick format options

    Standard hyphenated lowercase is the default and what almost every system expects. Toggle Uppercase or No dashes if your destination has stricter formatting requirements. The choice does not affect the underlying randomness — it is purely a string-level transformation after generation.

  3. Click Generate

    A fresh batch appears below. Each is independent and unique. Re-clicking generates a new batch — the old one is overwritten. The whole batch generates in milliseconds even for the maximum count of 100, because the randomness source is fast.

  4. Copy individual or all

    Each UUID has its own copy button (hover to reveal). Or use Copy All at the top to grab the whole batch as newline-separated text, ready to paste into a SQL INSERT, a CSV file, a fixtures.json, or a load test config. The newline-separated format is what most consumers expect.

Why use this tool

Database primary keys are the common case. PostgreSQL has a native uuid type, MySQL/MariaDB store them as char(36) or binary(16) for compact form, MongoDB defaults to ObjectId but accepts UUIDs as _id, DynamoDB happily takes them as partition keys, and most modern ORMs (Prisma, Drizzle, TypeORM) have first-class UUID support. UUIDv4 trades sequential write locality for the freedom to mint IDs on the client without a database round-trip — useful for offline-first apps, distributed writes across multiple regions, and avoiding the "leak my user count via auto-increment" pattern where /users/47 tells competitors how big you are. The second case is seeding test data: I need 50 unique IDs for a fixture and "Generate 50" is a click away. The third case is correlation IDs in logs. A web request gets a UUIDv4 attached at the edge; that ID propagates through every downstream call, and grepping for it gives you the full distributed trace across microservices. The fourth is generating share-link tokens or magic-link slugs where unguessability is the security property. UUIDv7 is the new hotness for sortable IDs with timestamp prefixes — this tool defaults to v4 because it is still the most widely supported format across all language ecosystems.

Features

Cryptographic randomness

crypto.randomUUID under the hood, which means 122 bits of entropy pulled from the OS-level CSPRNG (CryptGenRandom on Windows, /dev/urandom on Linux/macOS, getrandom() on newer kernels). Not Math.random — that would be wrong for IDs that need to be unguessable, since Math.random is a pseudo-random number generator with a finite state that can be inferred from output samples. The collision probability for UUIDv4 is so small you would need to generate hundreds of billions of UUIDs before having a meaningful chance of a duplicate.

Bulk generation up to 100

Set the count from 1 to 100 and get the whole batch in one click. Each is independently random, so generating 50 sequentially or one batch of 50 produces the same statistical distribution. Useful for seeding test databases, fixture files, load test inputs, or any other case where you need a chunk of unique IDs at once. For larger batches, run multiple generations and concatenate; the underlying randomness source has effectively unlimited capacity.

Format options

Toggle uppercase if your downstream system expects uppercase hex (some legacy COM-era Windows code does; the RFC actually requires lowercase but many real systems accept either). Toggle no-dashes if you need the 32-character compact form (some Mongo drivers accept either, some legacy DBs use compact form for storage efficiency). Both flags compose, so you can get the uppercase no-dash variant in two clicks. The standard form — lowercase hyphenated — is what every modern system expects and what RFC 4122 mandates.

Local generation, verified in DevTools

crypto.randomUUID runs in your browser. The UUIDs never touch a server. Important because UUIDs are sometimes used as session IDs, share-link tokens, magic-link slugs, or other identifiers where the server seeing them defeats the purpose of generating client-side. Open DevTools, click Generate, watch the Network tab — no outbound requests. The randomness comes from your operating system's CSPRNG, not from any remote service.

Version and variant bits visibly correct

Every UUID the tool emits has a 4 in position 13 (the version digit) and an 8, 9, a, or b in position 17 (the variant digit). Those six bits are not random — they identify the UUID as version 4 in the RFC 4122 family. If you paste a UUID elsewhere and it gets rejected as "invalid UUIDv4", check those two positions first. The remaining 122 bits are pure entropy from the OS CSPRNG. Trying to "fix" a UUID by hand-editing position 13 to a different digit will produce a string that looks like a UUID but is not version 4 and may be rejected by strict parsers in PostgreSQL (uuid_v4 functions) and other type-aware systems.

Privacy & security

crypto.randomUUID is a browser primitive that pulls bytes from the operating system's secure random source (CryptGenRandom on Windows, /dev/urandom on Linux and macOS) and lays them out per RFC 4122. Generating 1 UUID or 100 UUIDs takes no network calls — the function runs in your tab. This matters when the UUID is going to be used as a session ID, an unguessable share-link slug, or a magic-link token, because in those cases the server seeing the generated value would defeat the security property of generating it client-side.

Frequently asked questions

v4 versus v1 versus v7 — which one should I use?
v4 is fully random and the safest default. v1 embeds the MAC address and timestamp of the generating machine, which leaks information (you can sometimes trace a UUIDv1 back to a specific device and time) and creates predictability; almost no one uses v1 anymore for that reason. v7 is the new hotness from 2024 — it embeds a millisecond Unix timestamp at the front, making the IDs roughly sortable by creation time, which is great for B-tree indexes in databases (better locality than v4 means faster inserts and smaller indexes). v7 is what I would pick for a new system today; v4 is the safe choice when you do not know who or what is consuming the IDs or whether the consumer expects v4 specifically.
How likely is a collision?
For UUIDv4, you would need to generate about 2.71 quintillion UUIDs (2.71 × 10^18) before having a 50% chance of any duplicate, by the birthday bound. For practical scale — a system generating a million UUIDs per second — the heat-death of the universe would arrive first. Treat collisions as not happening. The math is the same as for any 122-bit random value: with N bits, you need 2^(N/2) values for a 50% collision chance, which here is 2^61.
Database primary keys — UUID or auto-increment integer?
UUIDs let you mint IDs on the client without a round-trip and avoid leaking row counts via sequential IDs. The cost is index size (16 bytes per UUID vs 4-8 for an int) and worse cache locality (random insertion scatters writes across the index B-tree, hurting insert throughput on large tables). UUIDv7 fixes the locality problem by being roughly sortable. For most web apps today, UUID is the right default; only consider integers if you have measured a real performance problem and confirmed the UUID is the bottleneck. ULID is another option in the same family — roughly sortable, 128-bit, lexicographically ordered.
Are crypto.randomUUID outputs cryptographically secure?
Yes. crypto.randomUUID, like all crypto.* methods in Web Crypto, draws from the OS-level CSPRNG (CryptGenRandom on Windows, /dev/urandom on Linux/macOS). That is the same source SSL libraries use for nonces and key material. Math.random is not cryptographically secure and should not be used for IDs that need to be unguessable — Math.random output is predictable from a few samples in some engines, and the V8 implementation has been reverse-engineered publicly.
Is the standard form 32 or 36 characters?
36 with hyphens, 32 without. The hyphenated 8-4-4-4-12 layout is canonical (e.g. 550e8400-e29b-41d4-a716-446655440000) and what most databases and APIs expect. Some drivers (older Mongo, some Go libs, some C libs) accept the dashless 32-char form. When in doubt, use hyphens — they are the RFC-mandated form and the universal default. If your destination strips them, fine; if it requires them, you are covered.
Why does my UUIDv4 always have a 4 at the 13th character?
That position is the version digit, fixed at 4 for v4. The 17th character is the variant digit and is always one of 8, 9, a, or b for RFC 4122 UUIDs. The remaining 122 bits are random. So out of the 128 total bits, 6 are deterministic format bits, 122 are entropy. This means a "UUID" that does not have 4 in position 13 is either not v4 or not RFC 4122 compliant — both of which exist in the wild but are not what this tool generates.
Can I generate a UUIDv1 or UUIDv7 with this tool?
Not currently. The tool emits v4 via crypto.randomUUID. For v7 you can use the uuid npm package (v9+) or any of the language-native libraries (Python uuid_utils, Go google/uuid v1.6+, Rust uuid crate). v1 is essentially deprecated and rarely worth generating. v6 (a reordered v1 for better sortability) and v8 (custom) also exist but are niche.
Are the generated UUIDs sent to a server?
No. crypto.randomUUID runs locally and the randomness comes from your OS. You can verify in DevTools — no fetch, no XHR, no beacon when you click Generate. Important if you are minting session IDs, share tokens, or any other identifier where the server learning the value defeats the purpose. The local-only design is what makes browser-based generation safe for those use cases.
What about ULID, CUID, NanoID — are those better than UUID?
ULID is a 128-bit identifier sortable by time (similar to UUIDv7 but with a different layout and a Crockford base32 encoding). CUID and CUID2 are designed for horizontal scalability and collision resistance with a more compact format. NanoID is a smaller (21 chars by default) URL-safe alternative. All have their use cases — ULID for sortable IDs in distributed systems, CUID for high-throughput web apps, NanoID for short URL slugs. If you need a UUID specifically (the database column type is uuid, the spec says UUID, the third-party API expects 36-char hyphenated form), generate one here. If you have flexibility, the alternatives are worth a look.
What is the NIL UUID and when would I use it?
The NIL UUID is the special all-zero value 00000000-0000-0000-0000-000000000000. RFC 4122 defines it as a sentinel — a deliberately invalid identifier that means "no UUID here yet" or "default". You use it when a column is non-nullable but the row has not been assigned a real UUID yet (a placeholder in a draft state machine), or as a magic value in test fixtures to mark something as unset. It is not random and has no version digit; the spec says you should not generate it accidentally. There is also a less-known "Max UUID" of all-Fs (ffffffff-ffff-ffff-ffff-ffffffffffff) added in RFC 9562 as a complementary sentinel. Neither will collide with a real UUIDv4 you generate here, so they are safe to use as placeholders alongside random IDs.
Walk me through the birthday-paradox math for UUIDv4 collisions.
The math says: for N random values drawn from a space of size 2^k, the probability of any pair colliding crosses 50% when N is roughly 2^(k/2). UUIDv4 has 122 bits of entropy (128 total minus 4 fixed version bits minus 2 fixed variant bits). So N for 50% collision is 2^61 ≈ 2.31 quintillion. The more cited figure of 2.71 quintillion comes from a slightly different approximation (the Taylor expansion gives sqrt(2 × ln(2) × 2^122) ≈ 2.71 × 10^18). Either way, the number is so large that even a system generating a billion UUIDs per second would take about 70 years to reach a 50% chance of any collision anywhere in its history. For practical purposes, collisions do not happen with v4. The reason UUIDv1 had a different reputation was its low-entropy timestamp + MAC layout, not the same statistical model.
Does using UUIDv4 in URLs cause any indexing or SEO problems?
No on indexing — Google indexes URLs with UUIDs the same as URLs with slugs. There is one practical caveat: a URL like /post/550e8400-e29b-41d4-a716-446655440000 carries no readable information about the content, so the URL itself contributes nothing to relevance signals. A URL like /post/2026-roundup-of-backup-tools tells Google something useful before the page is fetched. If you want the best of both, use a hybrid like /post/2026-roundup-of-backup-tools-550e8400 with a UUID prefix and a slug, where the route handler looks up by the UUID portion and ignores the slug (a la Stack Overflow URLs). For private resources where you specifically want unguessability — share links, password-reset URLs — the UUID-only form is actually the right choice.
Is my browser's crypto.randomUUID actually drawing from a real OS RNG?
Yes, in every major browser released since 2022. Web Crypto API specifies that crypto.getRandomValues and crypto.randomUUID must use a cryptographically secure source, which in practice means the OS-provided CSPRNG (CryptGenRandom on Windows, /dev/urandom or getrandom() on Linux, Apple's SecRandomCopyBytes on macOS). Older browsers without crypto.randomUUID fall back to crypto.getRandomValues plus manual UUID layout — same security properties, more code. The tool checks for crypto.randomUUID first and falls back if needed. The fallback is rare now; almost every browser shipped in the last three years has the API. To confirm yourself, run typeof crypto.randomUUID in your browser console — if it returns "function" you are on the modern path.