UUID Generator Online Free — v1, v4, v5 Explained
A UUID is a 128-bit identifier defined by RFC 4122. It looks like this: 550e8400-e29b-41d4-a716-446655440000. Developers reach for UUIDs when they need a unique key that no central authority has to issue — database primary keys, session tokens, API request IDs, file names, tracking pixels. The catch: three of the most common UUID versions work very differently, and picking the wrong one creates real problems. This guide covers all three versions, shows you how to generate a UUID free in the browser, and includes working code for JavaScript, Python, and Go.
- UUID v4 (random) is the right default for most applications — use it for database keys, session IDs, and API tokens
- UUID v1 embeds a timestamp and MAC address, which can leak server identity — avoid it in public-facing contexts
- UUID v5 produces the same output for the same input (namespace + name), making it useful for deterministic IDs
- The probability of a v4 collision across 1 billion UUIDs is roughly 1 in 10^18 (RFC 4122, IETF)
- Browser-generated UUIDs via
crypto.getRandomValues()are cryptographically secure — safe for tokens
Most developers have used a UUID without thinking much about how it works. That's usually fine — until it isn't. Choosing the wrong version can expose your server's MAC address, break deterministic ID generation, or produce non-sortable keys that slow down your database. Let's start from the beginning.
What Is a UUID and Why Do Developers Use It?
A UUID (Universally Unique Identifier) is a 128-bit number formatted as 32 hexadecimal digits in five groups separated by hyphens. It's defined by RFC 4122 (IETF, 2005). The standard defines five versions, each using a different generation strategy. The core appeal is decentralization: any system can generate a UUID without coordinating with a central registry or counter.
Auto-incrementing integers are simple for single-database setups. They break immediately in distributed systems, microservices, or any scenario where two nodes write records independently. UUID v4 solves this: each node generates its own IDs with no coordination, and the collision probability is so low it's treated as zero in practice.
Common uses include:
- Database primary keys. PostgreSQL has a native
UUIDcolumn type. MySQL, SQLite, and MongoDB all support UUIDs natively or as strings. - Session IDs. A v4 UUID is long enough and random enough to serve as a secure session token without any additional entropy.
- API request tracing. Assign a UUID to every incoming request for end-to-end tracing across microservices.
- File names. Rename uploaded files to a UUID before storage to prevent path traversal attacks and name collisions.
- Tracking pixels and event IDs. Each event gets a unique, non-guessable identifier that's safe to expose publicly.
UUID Versions Explained: v1, v4, and v5
RFC 4122 defines five UUID versions, but three dominate real-world use. UUID v1 encodes a timestamp and MAC address. UUID v4 uses 122 bits of cryptographic randomness. UUID v5 applies SHA-1 hashing to a namespace and a name string, always producing the same output for the same input. Choosing the wrong version causes privacy leaks (v1) or broken idempotency (v4 where v5 was needed).
UUID v1 — Timestamp + MAC address
Version 1 builds the UUID from the current timestamp (100-nanosecond intervals since October 15, 1582) combined with the generating node's MAC address. This makes v1 UUIDs sortable by generation time. It also means they're not random: two UUIDs generated on the same machine a few milliseconds apart are very similar, and anyone with the UUID can extract the generation time and a fingerprint of the source machine.
Privacy risk with v1: The MAC address embedded in a v1 UUID identifies the network interface card of the generating machine. This exposed server identity in early Amazon EC2 environments, which contributed to the shift away from v1 in cloud-native applications. Don't use v1 in any UUID that's visible to end users or logged externally.
UUID v4 — Cryptographically random
Version 4 sets 6 bits to fixed version/variant markers and fills the remaining 122 bits with random data. That's 2^122, or about 5.3 x 10^36, possible values. There's no timestamp, no MAC address, no structured data at all. It's the right default for almost every application. The only downside is that v4 UUIDs aren't sortable, which matters for certain database indexing strategies.
UUID v5 — SHA-1 hash of namespace + name
Version 5 takes a namespace UUID and a name string, runs them through SHA-1, and maps the result into UUID format. The same namespace and name always produce the same UUID. This is deterministic ID generation: useful when you need to generate a consistent ID for a known entity without storing a lookup table. A common pattern is generating a stable UUID for a URL, email address, or product SKU.
Quick version selector: Use v4 by default. Switch to v5 when you need the same ID for the same input across multiple systems. Only use v1 in closed internal systems where sortability matters and privacy leaks aren't a concern.
How to Generate a UUID Online Free (3 Steps)
The fastest way to generate a UUID without installing anything is to use a browser-based tool. The FusionPDF UUID generator produces v1, v4, and v5 UUIDs directly in your browser. No file is uploaded, no account is required, and the randomness comes from your device's own entropy source via the Web Crypto API. The whole process takes under 10 seconds.
Open the UUID generator. Go to fusionpdf.pro/uuid. No account, no sign-up, no install required. The tool runs entirely in your browser.
Select your UUID version. Choose v1 (timestamp + MAC), v4 (random, the default), or v5 (namespace + name). For v5, enter the namespace and name string in the fields that appear. For most uses, v4 is correct.
Copy your UUID. Click Generate. Your UUID appears instantly. Click Copy to add it to the clipboard. Need multiple UUIDs? Click Generate again for each one — every click produces a fresh, independent identifier.
How Does UUID v4 Randomness Work in the Browser?
Browser-generated UUID v4 values use the Web Crypto API's crypto.getRandomValues() method, which draws bytes from the operating system's entropy pool. This is the same source used by /dev/urandom on Linux and CryptGenRandom on Windows. According to the W3C Web Cryptography API specification, this source is required to be cryptographically secure.
Here's what happens under the hood when a browser generates a v4 UUID:
- The browser requests 16 random bytes from
crypto.getRandomValues() - Bits 12-15 of byte 6 are set to
0100(version 4) - Bits 6-7 of byte 8 are set to
10(RFC 4122 variant) - The 16 bytes are formatted as 32 hex characters with hyphens at positions 8, 12, 16, and 20
Only 6 bits are fixed. The remaining 122 bits are pure random data from the OS entropy pool. This means browser-generated v4 UUIDs are safe to use as session tokens or API keys, provided you use the full 36-character string and don't truncate it.
crypto.getRandomValues() method fills a typed array with cryptographically secure random values. The implementation draws from the platform's underlying random number generator — /dev/urandom on Linux/macOS, CryptGenRandom on Windows — which is seeded from hardware entropy sources including CPU timing jitter and interrupt events.
W3C Web Cryptography API specification, 2024
UUID vs. ULID vs. CUID vs. NanoID — Which Should You Use?
UUID v4 isn't the only decentralized unique ID scheme. ULID, CUID, and NanoID each solve specific limitations of UUID. The most important: UUIDs aren't URL-safe and aren't sortable by default. If your database's B-tree index suffers from UUID fragmentation, or you need IDs that sort chronologically, one of these alternatives may be a better fit.
| Format | Length | Sortable | URL-safe | Standardized | Best for |
|---|---|---|---|---|---|
| UUID v4 | 36 chars | No | With encoding | Yes (RFC 4122) | Database PKs, general use, maximum compatibility |
| UUID v7 (draft) | 36 chars | Yes | With encoding | Draft RFC | Database PKs where index locality matters |
| ULID | 26 chars | Yes | Yes | Community spec | Event logs, append-heavy tables, readable IDs |
| CUID2 | 24 chars | No | Yes | Community spec | Horizontal scaling, collision resistance at scale |
| NanoID | Configurable | No | Yes | Library | Short IDs in URLs, tokens, compact identifiers |
UUID v4 wins on compatibility: every major database, ORM, and language has native UUID support. ULID wins on sortability and URL-safety. NanoID wins on compactness. In our experience, UUID v4 is the right default unless you have a specific reason to choose otherwise — don't optimize prematurely for index locality.
What Are the Most Practical UUID Use Cases?
UUIDs solve a concrete problem: how to assign a unique identifier to a record without a central counter. PostgreSQL's native UUID type stores a 128-bit value in 16 bytes — more compact than a 36-character string and faster to index than VARCHAR(36). According to the PostgreSQL documentation, the UUID type uses 16 bytes of storage and supports all standard indexing strategies.
Database primary keys in PostgreSQL
Define a UUID column with gen_random_uuid() as the default to auto-generate v4 UUIDs at insert time. This function, available since PostgreSQL 13, draws from the same OS entropy pool as crypto.getRandomValues() in browsers. No extension required.
-- PostgreSQL: UUID primary key with auto-generation CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), user_id UUID NOT NULL, created TIMESTAMPTZ DEFAULT NOW() );
API endpoints and request tracing
Assign a UUID to every API request at the gateway level. Log it in every downstream service. When something breaks, search your log aggregator for that UUID and you get the complete trace across every service, with no coordination between teams needed.
File names for uploads
Never store uploaded files under their original names. A UUID filename prevents directory traversal attacks, collision between users who upload a file with the same name, and exposure of internal naming conventions. The original filename goes in a database column; the UUID goes in your object store.
Idempotency keys for payment APIs
Stripe, Braintree, and most payment processors accept an idempotency key with each request. Generate a v4 UUID before sending the request, store it locally, and retry with the same key if the network fails. The server guarantees the same response for the same key, preventing double-charges.
How Do You Generate a UUID in JavaScript, Python, and Go?
Every major language has UUID generation built in or available through a standard library. JavaScript gained native UUID generation in 2021 with crypto.randomUUID(), available in all modern browsers and Node.js 15+. Python's uuid module has been in the standard library since Python 2.5. Go uses the widely adopted google/uuid package, downloaded over 500 million times according to pkg.go.dev.
JavaScript (browser and Node.js)
// Browser or Node.js 15+ — no library needed const id = crypto.randomUUID(); // "110e8400-e29b-41d4-a716-446655440000" // Node.js < 15 or older browsers: use the 'uuid' package import { v4 as uuidv4 } from 'uuid'; const id = uuidv4(); // UUID v5 (deterministic — same input = same output) import { v5 as uuidv5 } from 'uuid'; const MY_NAMESPACE = '6ba7b810-9dad-11d1-80b4-00c04fd430c8'; const id = uuidv5('https://example.com/page', MY_NAMESPACE);
Skip the npm package in modern projects: crypto.randomUUID() is available natively in Chrome 92+, Firefox 95+, Safari 15.4+, and Node.js 15+. If your target environments are modern, you don't need the uuid npm package for v4 generation.
Python
import uuid # UUID v4 (random) — most common id_v4 = uuid.uuid4() print(str(id_v4)) # "550e8400-e29b-41d4-a716-446655440000" # UUID v5 (deterministic) id_v5 = uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com') print(str(id_v5)) # UUID v1 (timestamp + MAC — use only in closed internal systems) id_v1 = uuid.uuid1() print(str(id_v1))
Go
// go get github.com/google/uuid package main import ( "fmt" "github.com/google/uuid" ) func main() { // UUID v4 id, _ := uuid.NewRandom() fmt.Println(id.String()) // UUID v5 (deterministic) ns := uuid.NameSpaceURL id5 := uuid.NewSHA1(ns, []byte("https://example.com")) fmt.Println(id5.String()) }
Are UUIDs truly unique?
In practice, yes. UUID v4 has 122 bits of randomness, giving approximately 5.3 x 10^36 possible values. The probability of generating a duplicate across 1 billion UUIDs is roughly 1 in 10^18 — statistically negligible for any real application. You'd need to generate about 2.7 quadrillion v4 UUIDs before the collision probability reaches 50%. UUID collisions are a theoretical concern, not a practical one. (RFC 4122, IETF, 2005)
Can a UUID be reversed to find the source?
It depends on the version. UUID v1 embeds a timestamp (accurate to 100-nanosecond intervals) and the generating machine's MAC address, so it can reveal when and on which hardware a UUID was created. UUID v4 is pure random data — there's nothing to reverse. UUID v5 is a one-way SHA-1 hash of a namespace and name. The SHA-1 output cannot be reversed to recover the input. For public-facing IDs, v4 and v5 are safe; v1 is not.
What's the difference between UUID and GUID?
None, functionally. GUID (Globally Unique Identifier) is Microsoft's name for the same concept. Both follow the RFC 4122 standard and use the identical 8-4-4-4-12 hexadecimal format. Microsoft uses "GUID" in its APIs, .NET documentation, and Windows registry. The rest of the industry says "UUID." They are fully interchangeable in any system that accepts either format. If you see NEWID() in SQL Server, that generates a GUID — it's UUID v4 by another name.
Is UUID v4 cryptographically secure?
Yes, when generated correctly. UUID v4 requires a cryptographically secure random number generator (CSPRNG). In browsers, crypto.getRandomValues() draws from the OS entropy pool and meets this requirement. In Python, uuid.uuid4() uses os.urandom(), which is also cryptographically secure. The result is safe to use as a session token or API key. Don't truncate it: the full 128-bit value is required for the security guarantee to hold. (W3C Web Cryptography API, 2024)
What's the chance of a UUID v4 collision?
Extremely low. With 2^122 possible values, generating one billion UUIDs per second continuously would take over 85 million years to reach a 50% collision probability. For database use at typical scale — say, 100 million records — the expected number of collisions is approximately zero. The RFC 4122 specification itself states that collisions are "negligible" for all practical purposes. (RFC 4122, IETF, 2005)
Generate a UUID Free — Instant, No Signup
v1, v4, and v5 in your browser. Nothing is sent to any server. Generate one UUID or a thousand — all free, all local.