UUID generator

A UUID generator has two useful versions, not one default

UUIDs are 128-bit identifiers designed to be created independently. There is no central counter to contact and no registration request to make. That is the reason they work so well for database rows, API requests, queued jobs and files created on devices that may be offline. Two systems can assign identifiers before they meet, then merge their records without coordinating a number range first.

Version 4 and version 7 use that space differently. UUID v4 is almost entirely random. It says nothing about when it was made and is the conservative choice for public identifiers when creation time should stay private. UUID v7 begins with a millisecond Unix timestamp, followed by random bits. Its ordinary text representation therefore sorts by creation time across different milliseconds, which is useful for database indexes and event streams.

What “random” means here

These values come from crypto.getRandomValues, the Web Crypto source built into the browser. They do not come from Math.random, a timestamp with a few digits appended, or a server endpoint returning a prepared list. In UUID v4, six of the 128 bits mark the version and RFC variant, leaving 122 random bits. In v7, the first 48 bits carry time and the remaining available bits carry randomness around the required markers.

That makes collision fantastically unlikely; it does not turn probability into a registry. This page cannot certify that a particular value has never appeared anywhere else, and a UUID should not be sold as proof of ownership. If you need to compare a list generated by several systems, remove duplicate lines can expose an actual repeat without changing the order of the rest.

Why UUID v7 is easier on a database

Random primary keys scatter new rows across a B-tree index. That is not automatically a problem, but on write-heavy tables it means more page splits and poorer cache locality than keys whose leading bytes increase over time. UUID v7 puts the timestamp first while keeping enough randomness for independent writers, so newly created records tend to arrive near one another in the index without returning to a single database sequence.

Time-sortable does not mean every value in one batch is strictly increasing. A millisecond can contain many generated UUIDs, and the random field decides their order inside that millisecond. It also does not mean the clock is trustworthy: if a machine's time moves backward, its next timestamp moves backward too. Treat the ordering as useful locality, not as an audit log or an authorization decision.

When these IDs become primary keys in imported records, the conversion still needs to preserve them as strings. JSON to SQL shows the inferred column type before it writes statements, and CSV to SQL does the same for spreadsheet exports whose values have no declared type at all.

The timestamp is a feature and a disclosure

Anyone who sees a UUID v7 can recover its approximate creation millisecond from the first twelve hexadecimal digits. That can help diagnose event order, but it may also reveal when an account, document or request was created. Use v4 for externally visible links when even that small piece of timing information is sensitive. Neither version should carry access rights: an unguessable-looking identifier is not a password, and possession of it should never be the only authorization check.

The same distinction appears inside signed tokens. A JWT may use a UUID in its jti claim to identify one token, but uniqueness does not validate the token or its signature. The JWT decoder treats the whole token as a live credential and keeps signature verification separate from reading its claims.

Batch output stays deliberately plain

One UUID per line is useful because it can be pasted into a seed file, a spreadsheet column, a terminal pipeline or a test fixture without stripping commas or quotes. Choose any exact count from one through one thousand, copy the complete result, or download the same lines as UTF-8 text. A fresh batch calls the browser's cryptographic generator again for every item; changing version never converts or reuses the previous identifiers.

Some formats need identifiers with a more specific lifetime. An iCalendar event, for example, must keep the same UID when the meeting is updated or recipients get duplicates. The ICS file generator derives a stable event identifier and lets you carry the old one forward, rather than using a fresh UUID where stability is the actual requirement.

When a prepared list of IDs needs physical or camera-readable labels, the bulk QR code generator turns one value per row into separate PNG files in a ZIP. It preserves the UUID strings; it does not generate or replace them. For one styled symbol, the QR code generator applies colors or a logo and tests the finished raster before download.

Nothing leaves this tab

Generation is a small local byte operation. The version and variant bits are set here, the hexadecimal form is assembled here, and the optional text download is a browser Blob created from the result already on screen. There is no request containing the UUIDs and no account storing their history. Reloading clears the batch.

If an identifier needs to be tied to file contents rather than assigned independently, use a digest instead. A SHA-256 checksum changes when the bytes change; a UUID normally does not describe the bytes at all. The two strings may both look opaque, but one names an object and the other fingerprints content. Choosing between them is a data-model decision, not a formatting preference.