Short UUID Generator

Generate short, URL-safe 22-character base62 IDs that are collision-resistant — a compact alternative to standard UUIDs.

Number of IDs (1–100)

Each ID is 22 characters, base62 encoded (0–9A–Za–z), generated using crypto.getRandomValues().

About Short UUID Generator

Standard UUIDs are 36 characters (including hyphens). This tool encodes 128 bits of randomness as base62 (0–9A–Za–z), producing a 22-character string that is URL-safe and contains no special characters. IDs are generated using the browser's crypto.getRandomValues() API for cryptographically secure randomness, making collision probability negligible for virtually any application.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Producing a compact identifier for a URL where a full UUID with its dashes is unwieldy.
Generating an unguessable slug for a share link, where 128 random bits stop anyone finding other links by trying nearby values.
Seeding test fixtures or a database with up to 100 keys in one fixed 22-character format, copied as a list or downloaded as a text file.
Giving orders or tickets a public reference that reveals nothing about how many exist, as a sequential number would.
Naming uploads or export folders with letters and digits only, which every file system accepts without escaping.

How it works in practice

A worked example

A shop wants order-confirmation links shorter than a 36-character UUID, so a developer opens the page at its default of five IDs and checks what the strings really contain before writing the format into a database schema.

Input

Number of IDs (1–100)   5 (the page default)
Buttons                 none pressed; the page generates the IDs as it loads

Output

0D3wM0auv5VZSwv4rF5M2f
09ILp3Q90I32CahnzFwdFq
1GcHQW4r5uJetkkjB1vkTN
0qYV59AOKtNaIDNby0KgjJ
388SUyXaWmXX51OV6iuFJw

Each ID is 16 bytes from crypto.getRandomValues, read as one 128-bit number and written out in base62 (0–9, A–Z, a–z) as exactly 22 digits, with leading zeros kept. Twenty-two is the minimum, because 21 base62 digits reach only about 2^125, while 22 reach about 2^131, more than any 128-bit value needs. That headroom is why every ID starts with a digit from 0 to 7 and never a letter: across 200,000 generated IDs, the first position used only those eight symbols and every other position used all 62. All 128 bits are random, six more than a version 4 UUID carries, since nothing is set aside for version or variant fields. These five are one real run; a reload, a Regenerate press or a new count draws fresh bytes, so yours will differ.

The edge case that catches people

Decoding an ID back to 32 hex digits gives the 16 random bytes and nothing more, because generateShortId never sets the version and variant fields a UUID carries. The first ID above, 0D3wM0auv5VZSwv4rF5M2f, decodes to 06ec4b97-e1f0-0d8e-662c-fbbf2cbe7aa5, with 0 as its 13th digit and 6 as its 17th, where a version 4 UUID needs a 4 and one of 8, 9, a or b. Of the five, the third passes the uuid package's validate() as a version 3 and the fourth as a version 4, both by chance. Over two runs of 200,000 IDs, about 12.5% passed validate(), which accepts versions 1 to 8 with the standard variant, and about 1.6% were well-formed version 4, the 1 in 8 and 1 in 64 that random bits predict. Anything downstream that checks those fields rejects most of them.

When not to use this tool

It cannot shorten a UUID you already have. There is no box to paste one into, and every ID is fresh randomness, so nothing on this page maps back to an existing database key. If your records already carry UUIDs and you want short public forms of those same values, use a converter library such as the short-uuid package on npm, whose fromUUID() and toUUID() translate in both directions; its default alphabet is flickrBase58 rather than this page's base62. Generate here only when the short string itself is going to be the stored identifier.

Frequently Asked Questions

Why is it 22 characters rather than 36?: A UUID spends 36 characters on 128 bits: 32 hex digits of 4 bits each, plus four hyphens. A base62 digit carries about 5.95 bits, so 22 of them hold 128 random bits with room to spare, and leading zeros are kept, so every ID is exactly 22 characters long.
Can I turn one back into a UUID?: Not a valid one. Decoding gives back the 16 random bytes, which can be written as 32 hex digits, but the page never sets the version and variant fields a UUID carries, so about 7 in 8 fail the uuid package's validate(). Store the 22-character string itself as the identifier.
Can I cut an ID shorter to save space?: Only by giving up collision safety. Each character carries about 5.95 bits, so 8 characters keep about 47.6, and by the birthday bound there is a 1% chance of a repeat after about 2.1 million IDs. All 22 keep the full 128 random bits.
Can I pick a different alphabet?: Not here: the page writes base62 only. For 128 bits, base58 and base64url also need 22 characters, so the choice is about reading rather than length. Base58 drops 0, O, I and l, which helps anyone retyping an ID, while base64url adds - and _.
Are these sortable by time?: No. Every bit is random, so new IDs land at random points in a sorted index, which fragments a B-tree used as a primary key. For time-ordered IDs use ULID or UUIDv7, which put a timestamp in the leading bits.
Are short IDs safe in URLs and filenames?: In URLs, yes: base62 is only letters and digits, so nothing needs escaping. In filenames too, with one caveat: a case-insensitive file system, the Windows and macOS default, treats A and a as one letter, cutting the 128 bits of uniqueness to about 110, still far past any real risk of a clash.
Do short IDs collide sooner than full UUIDs?: No, later. A version 4 UUID has 122 random bits, since six are fixed for its version and variant, while these have all 128. By the birthday bound, a one-in-a-billion chance of any repeat takes about 825 trillion of these IDs, against about 103 trillion version 4 UUIDs.

Common errors and gotchas

Declaring the database column as a uuid type. These are 22-character base62 strings rather than hex, so store them as CHAR(22) text instead.
Storing IDs under a case-insensitive collation, such as the MySQL and SQL Server defaults, which treat two IDs that differ only in letter case as the same key.
Expecting time ordering. The IDs are pure randomness, so sorting them puts the oldest and newest rows in no meaningful order.
Assuming the shorter string is easier to say aloud. Base62 is case-sensitive, which makes dictation worse, not better.
Treating an unguessable identifier as an access control. It is a secret in a URL, and URLs leak into logs and referrers.