Free UUID v4 & v7 Generator & Decoder
Generate universally unique identifiers (UUID v4 and v7) instantly — or decode any existing UUID to reveal its version, variant, and embedded timestamp. No sign-up, no tracking, processed entirely in your browser.
Related Developer Tools
Last updated: May 20 2026
Reviewed by the QuickTooly Team
UUID Generator & Decoder Guide
Why Use QuickTooly's UUID Generator?
- UUID v7 support: Generate time-ordered UUIDs per RFC 9562 (2024) — sortable by creation time, ideal for database primary keys.
- Instant batch generation: Generate up to 20 UUIDs at once, copy individually or all at once.
- Built-in decoder: Paste any UUID to reveal its version, variant, and embedded timestamp (for v1 and v7).
- Private & secure: All generation and decoding happens in your browser — no server, no logs.
- 100% free: No account, no watermark, no limits.
What Is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value formatted as 32 hexadecimal digits separated by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Defined by RFC 4122 and updated in RFC 9562 (2024), UUIDs are designed to be globally unique without a central authority — making them ideal for distributed systems, databases, and APIs.
The 128-bit structure encodes a version number (character 13), a variant identifier (character 17), and version-specific payload such as random data or a timestamp. There are currently 8 standardized UUID versions (v1–v8), with v4 and v7 being the most widely used in modern applications.
UUID v4 vs UUID v7 — Which Should You Use?
Both v4 and v7 are collision-resistant and suitable for unique IDs, but they differ in structure and use case:
- UUID v4 (random): 122 bits of cryptographically random data. No embedded timestamp. Widely supported everywhere. Best for session tokens, API keys, and cases where creation order does not matter.
- UUID v7 (time-ordered): First 48 bits encode a Unix millisecond timestamp; remaining bits are random. Introduced in RFC 9562 (April 2024). Lexicographically sortable — database indexes stay ordered, reducing page splits and improving INSERT performance at scale.
Rule of thumb: Prefer v7 for database primary keys; prefer v4 for tokens and secrets where temporal ordering is irrelevant or undesirable.
UUID v7 Timestamp Explained (RFC 9562)
UUID v7 encodes the current Unix time in milliseconds in its first 48 bits (the first 12 hexadecimal characters). This means you can extract a precise creation timestamp from any v7 UUID — useful for auditing, debugging, and time-range queries without a separate created_at column. The remaining 74 bits are random, ensuring global uniqueness even when multiple UUIDs are generated within the same millisecond.
Example: the UUID 018f4e2a-1c3b-7d90-8f01-2b3c4d5e6f70 starts with 018f4e2a1c3b — converting that 48-bit hex to decimal gives the Unix timestamp in milliseconds, which corresponds to a specific date and time. The decoder above does this for you automatically.
How to Decode a UUID
Any UUID encodes metadata in fixed bit positions:
- Version — character at position 14 (13th zero-indexed). Values: 1 = time-based, 4 = random, 7 = Unix time-ordered.
- Variant — the high bits of character at position 19 identify the standard:
8–b= RFC 4122,c–d= Microsoft GUID,e–f= reserved. - Timestamp — for v7: first 12 hex chars as a 48-bit millisecond Unix epoch. For v1: a 60-bit 100-nanosecond counter since Oct 15, 1582, split across three fields.
Common UUID Use Cases
UUIDs are used wherever unique, non-sequential identifiers are needed: database primary keys (especially in distributed databases like PostgreSQL, MySQL, MongoDB), REST API resource IDs, session and authentication tokens, file and object names in cloud storage, event sourcing correlation IDs, and distributed tracing spans. UUID v7's sort-order property makes it especially attractive as a drop-in replacement for auto-increment integers in modern databases.
Frequently Asked Questions
What is the difference between UUID v4 and UUID v7?
UUID v4 is entirely random (122 random bits), while UUID v7 embeds a 48-bit Unix millisecond timestamp in its leading bits. The key practical difference is sortability: v7 UUIDs are lexicographically ordered by creation time, which improves database index performance. v4 generates a random, non-sequential value each time.
Is UUID v7 supported in production databases?
Yes. UUID v7 is defined in RFC 9562 (April 2024) and is supported as a storage type in PostgreSQL 17+, MySQL 8.4+, and all major databases that accept UUID/CHAR(36) columns. Any database that supports UUID v4 will accept v7 — the format is identical; only the content differs.
Can two UUIDs ever be identical?
Theoretically yes, but practically no. UUID v4 has 2¹²² possible values (~5.3 × 10³⁶). The probability of a collision when generating 1 billion UUIDs per second for 100 years is about 50% — far beyond any real-world scenario. UUID v7 adds a timestamp prefix which further reduces collision probability within any given millisecond.
Can I extract the creation time from a UUID v4?
No. UUID v4 is purely random and contains no timestamp. If you need to retrieve a creation time, switch to UUID v7 or store a separate created_at column alongside your v4 IDs.
What is the standard UUID string format?
A UUID is 32 lowercase hexadecimal digits arranged in five groups separated by hyphens: 8-4-4-4-12 characters, for a total of 36 characters including hyphens. Example: 550e8400-e29b-41d4-a716-446655440000. Uppercase variants are also valid per the spec.
Is it safe to use UUIDs as public-facing resource IDs?
Yes, with one caveat: UUID v7 embeds a timestamp, which means a determined observer could infer when a resource was created from its ID. If creation time is sensitive, use UUID v4 for public IDs. For internal systems where auditability is valued, v7's timestamp is often a feature rather than a risk.