UUID Generator

Unique IDs When You Need Them, Without the Ceremony

Database migrations, test fixtures, API development, file storage systems — all of them need unique identifiers at some point. UUID v4 is the universally accepted standard for random, collision-proof IDs that don't require a central issuing authority or any database round-trip.

Set how many you need, click generate, copy them all. No signup, no API call, no network request.

What a UUID Looks Like

f47ac10b-58cc-4372-a567-0e02b2c3d479

A UUID is a 128-bit value expressed as 32 hexadecimal characters grouped by hyphens in the pattern 8-4-4-4-12. The total length is always 36 characters including hyphens.

In UUID v4, the third group always starts with 4 (indicating version 4), and the fourth group always starts with 8, 9, a, or b (indicating the RFC 4122 variant). All other hex characters are randomly generated.

The Randomness Behind UUID v4

UUID v4 uses the browser's CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) via crypto.randomUUID() — the same source of randomness used for cryptographic key generation.

Collision probability: Two identical UUID v4 values would require generating approximately 2.71 quintillion UUIDs before reaching a 50% collision probability. For all practical engineering purposes, UUIDs are unique. No coordination with a central server is needed.

UUID Versions Compared

For general application use — primary keys, resource IDs, request traces — UUID v4 is the standard choice. If your database index performance is critical and you're inserting at very high volume, UUID v7's timestamp prefix solves the "random insert fragmentation" problem.

Real-World Use Cases

Database primary keys: UUID primary keys prevent ID enumeration attacks (attackers can't guess /users/1, /users/2...), make database sharding easier, and enable client-side ID generation before a row is inserted.

API request tracing: Assign a UUID as a X-Request-ID or Trace-ID header to every API call. This ties all log lines for a single request together across distributed services.

Test fixtures: Seed test databases with pre-generated UUIDs that won't conflict across environments or parallel test runs.

File storage naming: Name uploaded files by UUID (e.g., f47ac10b-58cc-4372-a567-0e02b2c3d479.pdf) to guarantee no filename collisions in cloud storage buckets.

Idempotency keys: Payment APIs use UUID idempotency keys so duplicate retries don't result in duplicate charges.

Frontend component IDs: React, Vue, and Angular components generating dynamic lists need stable, unique IDs for accessibility attributes and map keys.

Best Practices

Use v4 for most things. Unless you have a specific need for time-ordering (v7) or name-based determinism (v5), v4 is the right default.

Store as BINARY(16) in MySQL for performance. The common mistake is storing UUIDs as VARCHAR(36). A 16-byte binary column is 2.25× more compact and indexes 50–60% faster for point lookups.

Don't use UUID as a security token. UUID v4 is random, not secret. It shouldn't be used as a password, session token, or API key. For security-sensitive tokens, use a cryptographically random generator that keeps the value secret — UUID is designed for uniqueness, not secrecy.

Related Developer Tools

• JSON Formatter — Format JSON test fixtures using your generated UUIDs
• JWT Decoder — View the jti (JWT ID) claim, which is typically a UUID
• Base64 Encode/Decode — Encode UUIDs for use in API tokens or config

Recommended schema: SoftwareApplication + FAQPage