How To Generate UUID Online | Datafrog

What Is a UUID?

A UUID is a standardised 36-character string defined by RFC 4122. It follows a fixed pattern of 32 hexadecimal characters split into five groups by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where M is the version digit and N is the variant. A real UUID v4 example looks like this:

f47ac10b-58cc-4372-a567-0e02b2c3d479

That 4 in the third group tells you it's version 4. The structure isn't arbitrary — it carries meaning about how and when the identifier was created.

UUIDs solve a real problem in software: how do you create a unique ID across many systems, databases, or services without asking a central authority to hand one out? The answer is mathematical probability. A UUID v4 has 122 random bits, which means the chances of two UUIDs ever being identical are roughly 1 in 5.3 × 10³⁶ — a number so large it has no practical meaning as a risk.

UUID v1, v4, and v7 — What's the Real Difference?

The version number is not just a label. It tells you the exact algorithm used to generate the UUID, and that choice has real consequences for security, sortability, and database performance. Here is what each version actually does:

UUID v1 — Timestamp and MAC Address

UUID v1 combines a 60-bit timestamp (measured in 100-nanosecond intervals since October 1582) with your machine's MAC address. This makes it partially time-ordered and traceable — you can extract the creation time from a v1 UUID if needed.

The downside is privacy. Because a v1 UUID embeds your network card's MAC address, generating one on a server can inadvertently expose hardware information. For most modern applications, this is a reason to avoid v1 unless you have a specific need for timestamp traceability.

UUID v1 example:
6ba7b810-9dad-11d1-80b4-00c04fd430c8
          ↑ version 1

UUID v4 — Fully Random

UUID v4 is the most widely used version. It is generated entirely from cryptographically secure random numbers — 122 random bits — with no timestamp, no MAC address, and no system-specific data embedded anywhere. It tells you nothing about when or where it was created, which is exactly the point.

This makes UUID v4 the safe default for the vast majority of use cases: API tokens, session identifiers, user IDs, order references, and anything where uniqueness matters but order does not.

UUID v4 example:
550e8400-e29b-41d4-a716-446655440000
          ↑ version 4

UUID v7 — Time-Ordered and Sortable

UUID v7 is the modern answer to a real database problem. When you use random UUIDs (v4) as primary keys in a relational database, every new insert lands at a random position in the B-tree index. Over millions of rows, this causes excessive page splits and cache misses that hurt write performance.

UUID v7 fixes this by embedding a Unix millisecond timestamp in the first 48 bits. New records inserted in chronological order are also in lexicographic order, which keeps index pages contiguous and writes fast. It is now the recommended format for database primary keys in PostgreSQL, MySQL, and any system where you expect high insert volume over time.

UUID v7 example:
018fea3d-4b6c-7e2a-9f1b-3c5d8e0a1b2c
          ↑ version 7

How to Generate a UUID Online

DataFrog's online UUID generator runs entirely in your browser. Nothing is sent to any server. Here's how to use it:

1. Choose your UUID version — select UUID v1, v4, or v7 from the format dropdown depending on your use case. When in doubt, select v4.
2. Set the quantity — enter any number from 1 to 1000. Useful for bulk database seeding, load testing, or generating a list of test tokens.
3. Click Generate — your UUIDs appear instantly in the output panel.
4. Copy or export — copy all IDs to clipboard with one click, or download as CSV, JSON, Excel, SQL INSERT statements, or XML.

How to Generate a UUID in Code

When you need UUID generation built into your application rather than a one-off online tool, here are the native approaches for the most common languages:

JavaScript / Node.js

// Native — works in modern browsers and Node.js 19+
const id = crypto.randomUUID(); // UUID v4

// Using the uuid npm package (supports v1, v4, v7)
import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';
const idV4 = uuidv4();
const idV7 = uuidv7();

Python

import uuid

id_v4 = str(uuid.uuid4())  # UUID v4
id_v1 = str(uuid.uuid1())  # UUID v1

PostgreSQL

-- UUID v4 (built-in)
SELECT gen_random_uuid();

-- Use UUID as a primary key column type
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT
);

C# / .NET

// UUID v4 (called GUID in .NET)
Guid id = Guid.NewGuid();
string idString = id.ToString(); // "550e8400-e29b-41d4-a716-446655440000"

For anything beyond quick testing, use your language's native crypto library rather than a custom implementation. The online generator is best for one-off generation, testing, and working with formats your language doesn't natively support (like UUID v7 in older environments).

When Should You Use a UUID?

UUIDs are not always the right tool — but they are the right tool more often than most developers realise. Here is a practical breakdown:

• Database primary keys — use UUID v7 if you care about insert performance at scale; v4 otherwise.
• API request IDs — attach a UUID v4 to every request for distributed tracing and debugging.
• Session tokens — UUID v4 provides sufficient randomness for secure session identifiers.
• File naming in cloud storage — prefix filenames with a UUID to prevent overwrites in S3, GCS, or Azure Blob.
• Idempotency keys — send a UUID with API requests to safely retry without duplicate processing.
• Test data generation — bulk-generate UUIDs to seed a development or staging database.

Where UUIDs are not ideal: when you need human-readable IDs (use sequential integers or short codes), or when you need URL-safe compact identifiers (consider NanoID or ULID — covered in separate guides).

Storing UUIDs in a Database — the Right Way

How you store a UUID matters as much as how you generate it. Two common mistakes cost performance unnecessarily:

• Storing as VARCHAR(36) — this stores the 36-character hyphenated string as text. It works, but it uses more space and is slower to index than a native UUID type.
• Storing as CHAR(32) — slightly better (no hyphens), but still text-based and slower than binary.

The correct approach depends on your database:

• PostgreSQL — use the native UUID column type. It stores 16 bytes and indexes efficiently.
• MySQL 8+ — use BINARY(16) and store UUIDs with UUID_TO_BIN(uuid, true) (the true flag reorders bytes for better index locality with v1 UUIDs).
• MongoDB — use the native BinData subtype 3 or 4 for UUID storage rather than storing as a string.
• SQLite — no native UUID type; TEXT or BLOB are your options. BLOB is more efficient.

Conclusion

UUIDs are one of those foundational tools in software development that you reach for so often they become second nature. The key decisions are simple: use UUID v4 as your default for anything where randomness is the priority, switch to UUID v7 when your database needs time-ordered inserts, and use UUID v1 only if you have a specific need to trace creation timestamps.

For one-click generation — single or bulk — DataFrog's free UUID generator handles all three versions with export to CSV, JSON, SQL, Excel, and XML. Everything runs in your browser, nothing leaves your device.

Frequently Asked Questions